Professional Documents
Culture Documents
Software Aspects of Aeronautical Certification and Static Analysis Tools
Software Aspects of Aeronautical Certification and Static Analysis Tools
com 09/2010
Janvier 2010
Gérard LADIER
Page 2
Means of conformance
It is in general not
feasible to assess the
number or kinds of
software errors, if any,
that may remain after the
completion of system
design, development, and
test. DO-178B/ED-12B,
provides acceptable
means for assessing and
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Process T(q)
HLR
Define HLR's
Process T(q+1)
HLR(1)+ Implementation detail
Define HLR(1)
clean water
from a dirty
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
pipe
Process T(x)
Evidences are Produce Object
Object Code
requested on Code
the pipe …
Page 4
DO-178/ED-12 : evidences on the pipe …
• “DO-178B/ED-12B is primarily a process-oriented document”
=> Set of requirements on the processes (dev., verif, etc.) and
their outputs
• “The occurrence of any failure condition which would prevent the
continued safe flight and landing of the airplane is extremely
improbable”
=> Evidences on the fulfilment of these requirements vary
depending on the software “criticality” level
Applicabilité Catégorie de
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Page 6
Main common requirements on the developement
processes
• Standards must be written and evidences of compliance with the rules should be
provided
• Rules ?
Dozen of documents
Define precisely how to perform an activity (methods, means, constraints,
expected outputs, etc.
consistent
precise
tracable
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Each
developed requirement
or design item verifiable
should be
Page 7
Configuration management & Quality Assurance
Main characteristics :
Independence
Active role during the life cycle process
Page 8
Tools qualification -1
resulting software :
used to justify the elimination or reduction of:
Verification process other than that automated by the tool,
or Development process which could have an impact on the
resulting software
Criteria 3 : verification tool Page 9
Tools qualification - 2
– Combination of the
qualification criteria
with the
software level to
give the Tool
Qualification Level:
– The developper
• He defines his development specification (Tool Requirement-TR),
develops the tool and provides the life cycle data
TQL 4 :
– TQL 5 ones + «project management» requirements :
• TOR reviews (complete, accurate, and consistent)
• Definition of processes in plans
• Definition of the TR and verification / TOR
• Verification of the tool / TR et requirements coverage
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
detect and
eliminate
impurities
Page 12
Verification
• The most important section of DO-178/ED-12, in term of :
volume : 13 pages of description ( ~ 5 pages for other processes )
Workload incurred (A380 : 4 lines of test for line of embedded code …)
• Basic principles:
– “Integral” process => applies to all the development processes
– Combination of :
• Reviews ,
• Analysis
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
• Tests
to detect and identify errors
introduced during development
Page 13
Reviews ? Analysis ? Tests ?
• Three major tools for bug-busters :
Review : inspection of a product by an
independant (level A) person;
qualitative evaluation
expected ones
– Functional test
– NO TEST BASED ON CODE STRUCTURE
– Functional & Structural coverage analysis
Page 14
DO-178/ED-12 - The verification process
System
A-3.2 Accuracy & Consistency A-3.1 Compliance
A-3.3 HW Compatibility Requirements A-3.6 Traceability
Compliance: with requirements
A-3.4 Verifiability (A-2: 1, 2) Conformance: with standards
A-3.5 Conformance
A-3.7 Algorithm Accuracy
High-Level
Requirements A7 Verification of verification
(Functional & Structural coverage)
A-4. 8 Architecture Compatibility A-4.1 Compliance
A-4.6 Traceability
(A-2: 3, 4, 5)
A-4.9 Consistency A-4.2 Accuracy & Consistency
A-4.10 HW Compatibility A-4.3 HW Compatibility
A-4.11 Verifiability A-4.4 Verifiability
A-4.12 Conformance A-4.5 Conformance
A-4.13 Partition Integrity
Software Low-Level
Architecture A-4.7 Algorithm Accuracy
Requirements
A-5.2 Compliance
(A-2: 6) A-5.1 Compliance A-6.3 Compliance
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Potentially
opposite
interests are at
stake
Independant
authorities
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
assess the
process and
product
Page 16
The ED-12B/DO-178B - certification liaison
• Objective:
ensure effective communication/understanding between the
applicant and the certification authorities
• Means:
– The Plan for Software Aspects of Certification, given to the
Authorities as early as possible
– Reviews carried out by the certification
authorities “software” specialists
as much as they want
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
– Software Accomplishment
Summary and
Software Configuration Index.
Page 17
Fourth principe
updated by all
the concerned
specialists and
actors
Page 18
Consensus on requirements
• Joint meetings between the RTCA SC-205 EUROCAE WG-71
• Openness, consensus :
– More than 1200 people registered on the WEB site
– about 120 attendees in each meeting : aircraft manufacturers, engine
makers, equipment suppliers, authorities, scientists and consultants
– The final text has to be agreed by each of the attendees
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Page 19
DO-178C/ED-12C
Interface
• The « core document » will be Spec
completed by supplements :
Supplement A
Supplement –guidance used in conjunction DO-178C Supplement B
with DO-178C/ED-12C that addresses the
unique nature of a specific technology or a
specific method. A supplement adds, deletes ED-12C Supplement …
or otherwise modifies: objectives, activities,
explanatory text, and software life cycle data in
DO-178C/ED-12C.
DO-278A
/
DO-248C/ED-94C
ED-109A FAQ/DP/RATIONALE
Page 20
The DO-178C/ED-12C : evolution of the content
• Separation of the «why ?» part (>in the core doc) from the «how ?»
part (>supplement)
• Significant evolution of the « why ? »
Page 21
Formal Methods Technology supplement
• The FM introductory section insists on the interest of using FM for
verification
• The FA (Formal Analysis) may completely replace :
– Reviews & analysis (except for validation of « derived requirements »)
– Conformance test versus /HLR et /LLR
– Software integration tests
– Robustness tests
• FA may help for the verification of compatibility with the hardware
• FA cannot replace HW/SW integration test
• The structural coverage objectives are achieved if it can be demonstrated
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
that :
– Each requirement is completely covered
– The set of requirements is complete in regards of the attended function
– There is no non expected dependences between output and input data
– There is no dead code
Page 22
Fitfh principe
Only requirements
are mandatory, not
the means
Building the
« pipe » is to be
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Page 23
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Today
Which industrial use for Static Analysis tools ?
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Page 25
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Not so frequent …
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
How to convince certification Authorities ?
Tomorrow …
Which industrial use for Static Analysis tools ?
Tomorrow … 1
– FRAMA-C (CEA) :
• Plugin WP to succeed CAVEAT
• Plugin TASTER for syntaxic control (coding rules enforcement)
• Plugin for data flow/control flow verification, coming soon
Special thanks …
– David Delmas
Page 32
Made on http://www.wordle.net
© AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel.
Made on http://www.wordle.net
Page 33