RTCA SC-205: DO-178C - MicroWay Systems · 2008. 8. 25. · DO-178 and make proposed wording changes for a supplement in accordance with the IP420 concepts

August 19August 19--22, 2008 Denver22, 2008 Denver SW&CEH Conference SW&CEH Conference -- SG4 MBD&VSG4 MBD&V 11

ModelModel--Based DevelopmentBased Development&&

VerificationVerification

Mark Lillis, CoMark Lillis, Co--Chair Sub Group 4Chair Sub Group 4

RTCA SCRTCA SC--205: DO205: DO--178C178C

August 19-22, 2008 Denver SW&CEH Conference - SG4 MBD&V 2

AgendaAgenda

►►Model IntroductionModel Introduction►►Foundation Concepts Foundation Concepts ►►SGSG--4 Approach & Draft Status4 Approach & Draft Status►►Outlook & QuestionsOutlook & Questions


IntroductionIntroduction

►►RTCA Special CommitteeRTCA Special Committee--205 and EUROCAE 205 and EUROCAE Working GroupWorking Group--7171

►►Working on updates to DOWorking on updates to DO--178B/ED178B/ED--12B 12B ►►SubSub--Group 4 is working on Issues related to Group 4 is working on Issues related to

ModelModel--Based Development & Verification Based Development & Verification (MBD&V) of Airborne Software(MBD&V) of Airborne Software

►►Eurocae CoEurocae Co--Chair is Chair is Pierre LIONNE,Pierre LIONNE,System & Software Process Assurance at System & Software Process Assurance at EADS APSYS in ToulouseEADS APSYS in Toulouse


ModelsModelsA Summary of the TopicA Summary of the Topic


ModelsModels

►►This term This term modelmodel should be thought about should be thought about without restrictionswithout restrictions

Models define behaviorModels define behaviorThe behavior may be for: The behavior may be for: ►►Dynamic controlDynamic control►►StateState--based logicbased logic►►Sequential control logicSequential control logic►►Combinational control logicCombinational control logic►►Entire system architecturesEntire system architectures►►System and/or software verificationSystem and/or software verification


Not EveryoneNot Everyone’’s Model is Codables Model is Codable►► Plant Model: Represent the Engine, Airplane, or Plant Model: Represent the Engine, Airplane, or

other Realother Real--World World ““ItemItem”” that must be controlledthat must be controlled►► Models may be able to represent the Models may be able to represent the ““ItemItem”” in in

various environments, i.e. altitude, airspeed, various environments, i.e. altitude, airspeed, ambient temperature, etcambient temperature, etc…… and how they affect and how they affect the Itemthe Item’’s behaviors behavior

►► Some Plant models may be used to develop Some Plant models may be used to develop ““ControlControl”” modelsmodels

►► Model might be used just to create Model might be used just to create ““Expected Expected ResultsResults”” for verificationfor verification


Models vs. ToolsModels vs. Tools

►► There are ModelsThere are Models►► There are ToolsThere are Tools►► There are Modeling ToolsThere are Modeling Tools►► Model Model ≠≠ Modeling Tool Modeling Tool ≠≠ ToolsTools

Some Modeling Tools are part of a Qualified Some Modeling Tools are part of a Qualified Development EnvironmentDevelopment Environment

Different issues exist for each of theseDifferent issues exist for each of these


Where do models come from within Where do models come from within the requirements hierarchy?the requirements hierarchy?

►► Models: Are they high level requirements (HLR) or Models: Are they high level requirements (HLR) or low level requirements (LLR)?low level requirements (LLR)?

The answer is The answer is ““YES!YES!””

►► Different levels of models may be considered to be Different levels of models may be considered to be either high or low level requirements based on either high or low level requirements based on how they are developed and used.how they are developed and used.

This affects how the Annex Table Objectives are appliedThis affects how the Annex Table Objectives are applied

►► High Level Requirements come from the Systems High Level Requirements come from the Systems Process that is governed by ARP4754Process that is governed by ARP4754


System Design Model Allocated to System Design Model Allocated to Software and Hardware Software and Hardware

SoftwareModel

HardwareModel

Plant/EnvironmentModel

System Design/Architecture Model

System Requirements

System requirements allocated to software as

HLR model (DO-178)

System requirements allocated to hardware as

HLR model (DO-254)

Validate

Verify

Conformance

ComplianceTraceability

ComplianceTraceability

Conformance

See Examples #2 and #3

ARP4754


System Design Model Allocated to System Design Model Allocated to Software and Hardware Software and Hardware

►►The previous figure shows how a system The previous figure shows how a system design model can be used to allocate design model can be used to allocate portions or subportions or sub--models to software and models to software and hardware functionshardware functions

►►Two examples will be shown later where the Two examples will be shown later where the models allocated to software become HLR models allocated to software become HLR directly from the systems processdirectly from the systems process


High Level Requirements

Source Code

Executable Object Code

Model (LLR)Software

Architecture

System Requirements/Design

A-2: 1, 2

A-2: 3, 4, 5

A-2: 6

A-2: 7

A-3: 1, 6

A-3: 2, 3 ,4, 5, 7

A-5: 2A-5: 1, 5

A-4: 9, 10 ,11, 12, 13 A-4: 2, 3 ,4, 5, 7

A-5: 3, 4, 6

A-5: 7A-6: 5

A-6: 3, 4

A-6: 1, 2A-4: 8 A-4: 1, 6


Source Code


Model (LLR)Software

Architecture


A-2: 1, 2

A-2: 3, 4, 5

A-2: 6

A-2: 7

A-3: 1, 6

A-3: 2, 3 ,4, 5, 7

A-5: 2A-5: 1, 5

A-4: 9, 10 ,11, 12, 13 A-4: 2, 3 ,4, 5, 7

A-5: 3, 4, 6

A-5: 7A-6: 5

A-6: 3, 4

A-6: 1, 2A-4: 8 A-4: 1, 6

Supplemental High Level Requirements

Source Code


Model (HLR)

Software Architecture


A-2: 1, 2

A-2: 3

A-2: 6

A-2: 7

A-3: 1, 6A-3: 2, 3 ,4, 5, 7

A-5: 2

A-5: 1, 5

A-4: 9, 10 ,11, 12, 13

A-3: 2, 3 ,4, 5, 7

A-5: 3, 4, 6

A-5: 7A-6: 5

A-6: 1, 2

A-4: 8

A-3: 1, 6

A-2: 4, 5 are not applicableA-4: 1, 2, 3, 4, 5, 6, 7 are not applicable

A-6: 3, 4


Source Code


Model (HLR)



A-2: 1, 2

A-2: 3

A-2: 6

A-2: 7

A-3: 1, 6A-3: 2, 3 ,4, 5, 7

A-5: 2

A-5: 1, 5

A-4: 9, 10 ,11, 12, 13

A-3: 2, 3 ,4, 5, 7

A-5: 3, 4, 6

A-5: 7A-6: 5

A-6: 1, 2

A-4: 8

A-3: 1, 6

A-2: 4, 5 are not applicableA-4: 1, 2, 3, 4, 5, 6, 7 are not applicable

A-6: 3, 4


Source Code


Model (HLR)



A-2: 1, 2

A-2: 3

A-2: 6

A-2: 7

A-3: 1, 6A-3: 2, 3 ,4, 5, 7

A-5: 2

A-5: 1, 5

A-4: 9, 10 ,11, 12, 13

A-3: 2, 3 ,4, 5, 7

A-5: 3, 4, 6

A-5: 7A-6: 5

A-6: 1, 2

A-4: 8

A-3: 1, 6

A-6: 3, 4

Model (LLR)

A-4: 2, 3 ,4, 5, 7A-2: 4, 5

A-4: 1, 6


Source Code


Model (HLR)



A-2: 1, 2

A-2: 3

A-2: 6

A-2: 7

A-3: 1, 6A-3: 2, 3 ,4, 5, 7

A-5: 2

A-5: 1, 5

A-4: 9, 10 ,11, 12, 13

A-3: 2, 3 ,4, 5, 7

A-5: 3, 4, 6

A-5: 7A-6: 5

A-6: 1, 2

A-4: 8

A-3: 1, 6

A-6: 3, 4

Model (LLR)

A-4: 2, 3 ,4, 5, 7A-2: 4, 5

A-4: 1, 6



Model (LLR)Software

Architecture


A-2: 1, 2

A-2: 3, 4, 5

A-2: 6 is not applicableA-5: 4 is not applicable

A-2: 7

A-3: 1, 6

A-3: 2, 3 ,4, 5, 7

A-5: 2 A-5: 1, 5

A-4: 9, 10 ,11, 12, 13 A-4: 2, 3 ,4, 5, 7

A-5: 3, 6, 7A-6: 5

A-6: 3, 4

A-6: 1, 2

A-4: 8 A-4: 1, 6



Model (LLR)Software

Architecture


A-2: 1, 2

A-2: 3, 4, 5

A-2: 6 is not applicableA-5: 4 is not applicable

A-2: 7

A-3: 1, 6

A-3: 2, 3 ,4, 5, 7

A-5: 2 A-5: 1, 5

A-4: 9, 10 ,11, 12, 13 A-4: 2, 3 ,4, 5, 7

A-5: 3, 6, 7A-6: 5

A-6: 3, 4

A-6: 1, 2

A-4: 8 A-4: 1, 6

Model as a Low Level Requirement

Model as a Low Level & High Level Requirement

Model as a High Level Requirement

Model direct to Code


SG4 MethodologySG4 MethodologyThe Pathway to an MBD&V The Pathway to an MBD&V

SupplementSupplement


SG4 MethodologySG4 Methodology►► Since the team had a wide array of perspectives on Since the team had a wide array of perspectives on

models, early consensus was impossiblemodels, early consensus was impossible►► Considerable effort was expended in generating Considerable effort was expended in generating

Foundation PapersFoundation Papers to help shape our common to help shape our common understanding of the model usage issuesunderstanding of the model usage issues

►► The final result was a distilled version of our The final result was a distilled version of our understanding and agreement on these foundation understanding and agreement on these foundation conceptsconcepts

Issue Paper #420 serves to hold these conceptsIssue Paper #420 serves to hold these concepts►► SG4 divided into groups to tackle each section of SG4 divided into groups to tackle each section of

DODO--178 and make proposed wording changes for a 178 and make proposed wording changes for a supplement in accordance with the IP420 conceptssupplement in accordance with the IP420 concepts


IP

420 ED-12B

DO-

178B

1: MODELLING TECHNIQUES MAY BE SUITABLE TO EXPRESS…

15: MODEL SIMULATORS MAY BE… IP420IP420

Foundation ConceptFoundation Concept


IP420 IP420 -- Foundation ConceptsFoundation Concepts

►► Concepts are a basis to be used to write a complete Concepts are a basis to be used to write a complete document in which more precise guidance should be document in which more precise guidance should be elaborated elaborated

15 separate & complementary concepts were formed15 separate & complementary concepts were formed

►► The aim of these concepts is to make everybody aware of The aim of these concepts is to make everybody aware of the principles adopted by SGthe principles adopted by SG--4 in the writing of the MBD&V 4 in the writing of the MBD&V guidanceguidance

►► It is obvious that some aspects of the MBD&V issues are It is obvious that some aspects of the MBD&V issues are not yet addressed in this papernot yet addressed in this paper

►► To be tailored according to the design assurance levelTo be tailored according to the design assurance level



Usage of modelsUsage of models

►► Modelling techniques may be suitable to express Modelling techniques may be suitable to express requirement and/or design and/or architecture lifecycle requirement and/or design and/or architecture lifecycle data items.data items. (#1)(#1)

OROR

►► Modelling techniques may be suitable to express HLR Modelling techniques may be suitable to express HLR and/or LLR and/or architecture lifecycle data items. and/or LLR and/or architecture lifecycle data items. (#1)(#1)



System vs. Software (1)System vs. Software (1)

►► MBD&V aspects may be in both the system and the MBD&V aspects may be in both the system and the software area.software area.However, the MDB&V guidance only address the models However, the MDB&V guidance only address the models that are involved in the production of the software that are involved in the production of the software development lifecycle items.development lifecycle items.This does not exclude the models representing system This does not exclude the models representing system lifecycle data items.lifecycle data items.The guidance is not applicable to models representing The guidance is not applicable to models representing system and only system lifecycle data items. system and only system lifecycle data items. (#4)(#4)



System vs. Software (2)System vs. Software (2)

►► The guidance contained in the supplement should apply The guidance contained in the supplement should apply regardless of who performs the modelling activities: regardless of who performs the modelling activities: system engineers or software engineers.system engineers or software engineers.The job title of the engineer shall not determine the The job title of the engineer shall not determine the process they are required to follow.process they are required to follow. (#5)(#5)

►► System requirements, which may exist in model form, System requirements, which may exist in model form, should be validated in accordance with the applicable should be validated in accordance with the applicable guidelines (ARP4754).guidelines (ARP4754). (#13)(#13)



Decomposition (1)Decomposition (1)

►► The modelling process may produce several models, The modelling process may produce several models, having different levels of abstraction.having different levels of abstraction. (#3)(#3)

►► At a given level of abstraction, a model can express a set At a given level of abstraction, a model can express a set of requirements and/or design and/or architecture:of requirements and/or design and/or architecture:

At times, several modelling techniques may be required to expresAt times, several modelling techniques may be required to express the s the complete set of requirements or design.complete set of requirements or design.

At times, the used modelling techniques may not be suitable to eAt times, the used modelling techniques may not be suitable to express xpress the complete set of requirements or design.the complete set of requirements or design. (#8)(#8)



Decomposition (2)Decomposition (2)

►► Whenever modelling techniques are not suitable as Whenever modelling techniques are not suitable as specified in item 8, complementary information should be specified in item 8, complementary information should be given by another means to augment that which is given by another means to augment that which is represented in the model.represented in the model. (#9)(#9)



StandardsStandards

►► Modelling standards shall be defined and used for each Modelling standards shall be defined and used for each modelling technique.modelling technique.

The standard shall provide a means to satisfy all traceability The standard shall provide a means to satisfy all traceability expectations.expectations.The standard shall provide the semantic and syntax description oThe standard shall provide the semantic and syntax description of f the model used.the model used. (#2)(#2)

►► At any level of abstraction, the used modelling techniques At any level of abstraction, the used modelling techniques shall be appropriate to represent the requirements and/or shall be appropriate to represent the requirements and/or design without any ambiguity.design without any ambiguity.Modelling standards will address this expectation.Modelling standards will address this expectation. (#7)(#7)



Derived RequirementsDerived Requirements

►► At any level of abstraction, a model can contain derived At any level of abstraction, a model can contain derived requirements.requirements. (#10)(#10)

►► All derived requirements shall be identified.All derived requirements shall be identified. (#11)(#11)

►► All derived requirements shall be justified, validated and All derived requirements shall be justified, validated and assessed for potential safety impact.assessed for potential safety impact. (#12)(#12)



Verification (1)Verification (1)

►► Each lifecycle data item output from the modelling process shallEach lifecycle data item output from the modelling process shall be be verified.verified.

Each successive level of abstraction shall be consistent with itEach successive level of abstraction shall be consistent with its parent s parent requirements.requirements.

Each successive level of abstraction shall be compliant with theEach successive level of abstraction shall be compliant with themodelling standards.modelling standards.

The verification evidence burden shall not be reduced by the The verification evidence burden shall not be reduced by the applicantapplicant’’s choice to use MBD&V.s choice to use MBD&V.Informal models can be created to validate requirements and Informal models can be created to validate requirements and produce validation cases for the delivered system, but shall notproduce validation cases for the delivered system, but shall not be be used directly as development process artefacts without full used directly as development process artefacts without full verificationverification (#14)(#14)



Verification (2)Verification (2)

►► Model simulators may be used to support the Model simulators may be used to support the demonstration of the correctness and completeness of demonstration of the correctness and completeness of the models.the models. (#15)(#15)


Current DraftCurrent DraftIPIP--440440


How did we get to the current draft?How did we get to the current draft?

►►Drafts were presented in Vancouver and Drafts were presented in Vancouver and Toulouse and considerable feedback was Toulouse and considerable feedback was receivedreceived

►►FORMAT ISSUES: Concerned with length, FORMAT ISSUES: Concerned with length, complexity of table format, handling of complexity of table format, handling of annex tablesannex tables

►►TECHNICAL ISSUES: Concerned about TECHNICAL ISSUES: Concerned about applicability, need for a supplement, scopeapplicability, need for a supplement, scope


IPIP--433 & IP433 & IP--436436

►► Considerable comments on IPConsiderable comments on IP--433 Draft encouraged a sub433 Draft encouraged a sub--team to look at a new approachteam to look at a new approach

►► Parallel efforts on both new & old document approaches Parallel efforts on both new & old document approaches occurred for several monthsoccurred for several months

►► The simplified approach incorporated into IPThe simplified approach incorporated into IP--436 was 436 was adopted in Paris and refined in Toulouse as IPadopted in Paris and refined in Toulouse as IP--436436

►► A goA go--forward approval was given in Toulouse and work on forward approval was given in Toulouse and work on a furthera further--simplified approach is now called IPsimplified approach is now called IP--440440

►► IPIP--440 is an evolutionary change to IP440 is an evolutionary change to IP--436 that, hopefully, 436 that, hopefully, will address all major issues to both format & technical will address all major issues to both format & technical approachapproach


Example of Table ChangesExample of Table Changes

Table MBDV A-1

Objective Applicabilityby

SW Level

Output Control Category

by SW level Description Ref. A B C D Description Ref. A B C D

5 Model development standards are defined.

MBDV 4.1

MBDV 4.5

SW Model Standards MBDV11.21

LEGEND: The objective should be satisfied with independence.

The objective should be satisfied.

Blank Satisfaction of objective is at applicant’s discretion.

Data satisfies the objectives of Control Category 1 (CC1).

Data satisfies the objectives of Control Category 2 (CC2).

Applicability of the Supplement objectives with respect to the Core Document

Models Used to Define High Level Requirements

Models Used to Define Low Level Requirements

Models Used to Define Architecture

DO-178C Core Document Annex

A Table Objectives Substitutions Additions Substitutions Additions Substitutions Additions

A-1 Objective 1 None None None None None None A-1 Objective 2 None None None None None None A-1 Objective 3 None None None None None None A-1 Objective 4 None None None None None None

A-1 Objective 5 None MBDV A-1 Objective 5 None

MBDV A-1 Objective 5 None

MBDV A-1 Objective 5

A-1 Objective 6 None None None None None None A-1 Objective 7 None None None None None None


Example of Annex TablesExample of Annex Tables

Table MBDV A-2

Objective Applicabilityby

SW Level

Output Control Category

by SW level Description Ref. A B C D Description Ref. A B C D

1 Models are developed.

MBDV 5.6.1a MBDV 5.6.2a MBDV 5.6.2b MBDV 5.6.2c MBDV 5.6.2d MBDV 5.6.2e MBDV 5.6.2f

Software Requirements Data 11.9

2 Derived model elements are provided to the system safety assessment.

MBDV 5.6.1b MBDV 5.6.2c

Software Requirements Data 11.9

3 Models are developed.

MBDV 5.6.1a MBDV 5.6.2a MBDV 5.6.2b MBDV 5.6.2c MBDV 5.6.2d MBDV 5.6.2e MBDV 5.6.2f

Design Description 11.10


New Modeling Glossary TermsNew Modeling Glossary Terms►► ModelModel –– An abstract representation of a given set of aspects of a systeAn abstract representation of a given set of aspects of a system that is m that is

used for analysis, simulation and/or code generation and that haused for analysis, simulation and/or code generation and that has an s an unambiguous, well defined syntax and semantics.unambiguous, well defined syntax and semantics.

Note 1Note 1:: If the representation is just presented (visualized) as a drawinIf the representation is just presented (visualized) as a drawing with no g with no well defined language, the development is not considered to be iwell defined language, the development is not considered to be in the scope of this n the scope of this document. document. Note 2Note 2:: The language used to represent the model may be defined as a metThe language used to represent the model may be defined as a metaa--model but is not part of the model.model but is not part of the model.Note 3Note 3:: The given set of aspects of a system may contain all aspects of The given set of aspects of a system may contain all aspects of the the system or only a subset.system or only a subset.

►► Model ArchitectureModel Architecture –– The structure of the Model selected to implement its The structure of the Model selected to implement its HigherHigher--Level Requirements.Level Requirements.

►► ModelModel--Based DevelopmentBased Development –– A development process in which the primary A development process in which the primary software artifacts are represented by models from which other arsoftware artifacts are represented by models from which other artifacts, for tifacts, for example source code, are generated.example source code, are generated.

►► Model CategoryModel Category –– The classification of a model according to the life cycle data The classification of a model according to the life cycle data the model represents.the model represents.

ExampleExample: Software High: Software High--Level Requirements Model, Software Architecture Model.Level Requirements Model, Software Architecture Model.


New Modeling Glossary TermsNew Modeling Glossary Terms

►► Software Architecture ModelSoftware Architecture Model –– A Model representing part A Model representing part or all of the Software Architecture. or all of the Software Architecture.

ExampleExample: UML Class Model.: UML Class Model.

►► Software HighSoftware High--Level Requirements ModelLevel Requirements Model –– A Model A Model representing part or all of the Software Highrepresenting part or all of the Software High--Level Level Requirements.Requirements.

►► Software LowSoftware Low--Level Requirements ModelLevel Requirements Model –– A Model A Model representing part or all of the Software Lowrepresenting part or all of the Software Low--Level Level Requirements.Requirements.

►► Software Verification ModelSoftware Verification Model –– A Model representing A Model representing Software Verification Cases, Procedures and Results or Software Verification Cases, Procedures and Results or components of verification tools.components of verification tools.


More Glossary Terms IntroducedMore Glossary Terms Introduced►► Model SimulatorModel Simulator –– A device, computer program or system which A device, computer program or system which

enables the execution of a model to demonstrate its behavior in enables the execution of a model to demonstrate its behavior in support of verification and/or validation.support of verification and/or validation.

NoteNote:: This simulator may be executing code that is not representative This simulator may be executing code that is not representative of the target code.of the target code.

►► Model TransformationModel Transformation –– The Process of transforming a Model into The Process of transforming a Model into another Modelanother Model

ExampleExample: Transformation of a dataflow Model designed in one modeling : Transformation of a dataflow Model designed in one modeling tool into a dataflow Model designed in another modeling tool.tool into a dataflow Model designed in another modeling tool.

►► Model ViewModel View –– A subset or all of a Model for a specific purpose.A subset or all of a Model for a specific purpose.ExampleExample: A View of an Entity Relationship Model would select a set of : A View of an Entity Relationship Model would select a set of entities and their relationships to other selected entities for entities and their relationships to other selected entities for the specific the specific purpose.purpose.

►► Model ExecutionModel Execution –– The process of exercising a Model on a Model The process of exercising a Model on a Model Simulator to verify that it satisfies specified requirements andSimulator to verify that it satisfies specified requirements and to detect to detect errors.errors.


AutoAuto--coding Glossary Termscoding Glossary Terms►► AutoAuto--Code GeneratorCode Generator –– A Software Tool that transforms a Model into Code.A Software Tool that transforms a Model into Code.

NoteNote:: Automated code generation may take place in different software Automated code generation may take place in different software processes. If automated code generation is applied in the softwaprocesses. If automated code generation is applied in the software coding process re coding process then the process activities defined in DOthen the process activities defined in DO--178C/ED178C/ED--12C section 5.3 are automated. If 12C section 5.3 are automated. If automated code generation is applied in Processes other than theautomated code generation is applied in Processes other than the software coding software coding process, some or all of the modelprocess, some or all of the model--based Process inputs may be used to generate based Process inputs may be used to generate Simulation Code. For example, a HighSimulation Code. For example, a High--Level Requirements Model could be subject to Level Requirements Model could be subject to an automated code generation resulting in Simulation Code for Exan automated code generation resulting in Simulation Code for Execution of the ecution of the Model.Model.

►► AutoAuto--Model TransformerModel Transformer –– A Software Tool implementing Model A Software Tool implementing Model Transformation.Transformation.

►► AutoAuto--Model Transformer / AutoModel Transformer / Auto--Code Generator SetupCode Generator Setup –– The activity/result of The activity/result of setting up an Autosetting up an Auto--Model Transformer or AutoModel Transformer or Auto--Code Generator for the Code Generator for the intended purpose.intended purpose.

Note 1Note 1:: The term is used to synonymously identify the activity and the rThe term is used to synonymously identify the activity and the result.esult.Note 2Note 2:: In contrary to the setup of other tools within the software In contrary to the setup of other tools within the software development/verification environment the Autodevelopment/verification environment the Auto--Model Transformer /AutoModel Transformer /Auto--Code Code Generator Setup is an activity which is part of the software proGenerator Setup is an activity which is part of the software process automated by cess automated by the application of Autothe application of Auto--Model Transformer /AutoModel Transformer /Auto--Code Generator, as setup decisions Code Generator, as setup decisions directly correspond to decisions made by a software developer whdirectly correspond to decisions made by a software developer when performing the en performing the software process manually.software process manually.


FAQ HighlightsFAQ Highlights

►► FAQ: What should be the basis for test cases FAQ: What should be the basis for test cases for executable object code for which the low for executable object code for which the low level requirements are in a model?level requirements are in a model?

►► Answer:Answer:In this case, models are expressions of how a given set In this case, models are expressions of how a given set of software higher level requirements should be of software higher level requirements should be implemented. Therefore, test cases for the executable implemented. Therefore, test cases for the executable object code generated from a model should not only be object code generated from a model should not only be based on the modelbased on the model but also on the higher level but also on the higher level requirements for the modelrequirements for the model..



►► FAQ: Is it required to test the executable object FAQ: Is it required to test the executable object code generated from the model on the target?code generated from the model on the target?

►► Answer:Answer:If the tool chain that generates executable object code from theIf the tool chain that generates executable object code from themodel is not qualified for the target computer, then all testingmodel is not qualified for the target computer, then all testing must must be performed on the target or a target emulator as specified in be performed on the target or a target emulator as specified in DODO--178C. 178C. If the tool chain that generates or verifies executable object cIf the tool chain that generates or verifies executable object code ode from the model is qualified for the target computer, then at leafrom the model is qualified for the target computer, then at least st the following testing must be performed on the target or a targethe following testing must be performed on the target or a target t emulator as specified in DOemulator as specified in DO--178C:178C:►► RequirementsRequirements--based hardware/software integration testing.based hardware/software integration testing.



►► FAQ: What is the benefit of performing FAQ: What is the benefit of performing coverage analysis on a model?coverage analysis on a model?

►► Answer:Answer:The benefit of performing coverage analysis with the The benefit of performing coverage analysis with the associated coverage analysis resolution on a model is to associated coverage analysis resolution on a model is to supplement the requirementssupplement the requirements--based coverage analysisbased coverage analysis. . Examples of supplementary analysis, with corresponding Examples of supplementary analysis, with corresponding verification objectives are as follows:verification objectives are as follows:►►Provide evidence of the thoroughness of modelProvide evidence of the thoroughness of model’’s requirementss requirements--

based testingbased testing►►Provide evidence that the complete model structure was Provide evidence that the complete model structure was

verifiedverified


Wrap UpWrap UpWhere We Are GoingWhere We Are Going


Fall 2008Fall 2008

►►The Supplement Format finalizing for SGThe Supplement Format finalizing for SG--44►►Chicago meeting scheduled for September Chicago meeting scheduled for September

to finalize draft based on IPto finalize draft based on IP--440440►►Changes to document format may affect our Changes to document format may affect our

plans (EARLY October chairplans (EARLY October chair’’s meeting)s meeting)►►November Plenary meeting will present November Plenary meeting will present

latest draftlatest draft


Thank YouThank YouQuestions???Questions???


AcknowledgementsAcknowledgementsThis presentation contains the work of the entire SG4 committee,This presentation contains the work of the entire SG4 committee, thank you thank you

to all that contributed.to all that contributed.

SG4 WebsiteSG4 Websitehttp://forum.pr.erau.edu/SCAS/http://forum.pr.erau.edu/SCAS/

SG4: Model Based Design and VerificationSG4: Model Based Design and VerificationSG4 Model Based Design and Verification: Working Materials and DSG4 Model Based Design and Verification: Working Materials and Discussionsiscussions

Contact InformationContact [email protected]@HS.UTC.COM

http://forum.pr.erau.edu/SCAS/

Documents

RTCA SC-205: DO-178C - MicroWay Systems · 2008. 8. 25. · DO-178 and make proposed wording changes for a supplement in accordance with the IP420 concepts