PDF资料：自动驾驶汽车软件单元测试

HEICON Global Engineering GmbH Kreuzweg 22, 88477 Schwendi Internet: www.heicon-ulm.de Blog: http://blog.heicon-ulm.deSoftware unit testing: Aerospace best practices usable in autonomous vehicles?HEICON –Global Engineering GmbHHEICON is a specialized engineering company which provides consulting-and development support with a focus on software-based embedded systems.The efficient implementation of methods and processes is the area of our engagement. Founding:2018 Headquarter:Schwendi near Ulm Membership:Revenue Distribution:71%72%39%16%23%20%28%36%35%6%18%14%4%3%10%11%19%1%2%8%19%18%2%8%4%5%7%0%10%20%30%40%50%60%70%80%90%100%20132014201520162017Other Sectors Military Space RailwayIndustrial Automation Automotive AerospaceUnit Tests considerationsComparison Aerospace and Automotive Industry Examples for different Interpretation of the Standards Best Practice AerospaceContact✓ISO 26262 und IEC 61508 require such tests.✓The Aerospace (DO178) does have more than30 years of experience in doing this kind oftesting.✓Software Unit Tests providing a 100%structural source code Coverage, find softwarebugs early.✓To create the required documentation (TestCases, Test Procedures, Test Reports,Traceability) for SW Unit Tests is costly andtakes a lot of time.✓Therefore efficient ways to create these testsare essential.Main.c(Scheduler)Function 1Function 2Function 3FBlock1.1.cFunction 1Function 2FBlock1.2.cFunction 1Function 2 Function 3 Function 4 Function 5 Function 6FBlock2.3.cFunction 1Function 2Function 3Function 4Function 5FBlock2.1.cFunction 1Function 2Function 3Function 4Function 5Function 6Function 7FBlock2.2.cFunction 1Function 2S o ft w ar e U n it t e stS o f tw a r e /So f t w a reI n t e g r at i o n s t es t 1Sof twa re/S oftw are Inte grat ions test 2Main.c (Scheduler)Function 1Function 2Function 3FBlock1.1.c Function 1Function 2FBlock1.2.c Function 1Function 2Function 3Function 4Function 5Function 6FBlock2.3.c Function 1Function 2Function 3Function 4Function 5FBlock2.1.c Function 1Function 2Function 3Function 4Function 5Function 6Function 7FBlock2.2.c Function 1Function 2Unit Tests considerationsComparison Aerospace and Automotive Industry Examples for different Interpretation of the Standards Best Practice AerospaceContactSystem ArchitectureHigh-Level RequirementsLow-Level RequirementsUnittestHW/SW Integration Test System Test 12System Architecture SW Architecture DesignCodingRequirements –Aerospace:✓Normal Test Cases✓Robustness Test Cases ✓100% Structural Coverage+Requirements –Automotive: System designSoftware unit design and implementation Software unittestingItem integrationand testingSpecification of Software safety requirementsSoftware architectural designSoftwareintegration andtestingVerification ofsoftware safetyrequirements Item testingSoftware testingSoftwaretestingSoftwaretestingRequirements:Aerospace -DO-178C Applicability by SW LevelVerification of Outputs of Software Requirements Process A B C DHigh-level requirements comply with system requirementsHigh-level requirements are accurate and consistentHigh-level requirements are compatible with target computerHigh-level requirements are verifiableHigh-level requirements conform to standardsHigh-level requirements are traceable to system requirementsAlgorithms are accurate Automotive -ISO 26262 –Part 6 Chapter 6: Specification of software safety requirementsRequirements:Aerospace -DO-178C Applicability by SW LevelVerification of Outputs of Software Design Process A B C DLow-level requirements comply with high-level requirementsLow-level requirements are accurate and consistentLow-level requirements are compatible with target computerLow-level requirements are verifiableLow-level requirements conform to standardsLow-level requirements are traceable to high-levelrequirementsAlgorithms are accurateAutomotive-ISO26262 –ASIL A ASIL B ASIL C ASIL D Notation for software unit designNatural language++++++++Informal notations++++++Semi-formal notations+++++++Formal notations++++Structural Coverage:Aerospace -DO-178C Applicability by SW LevelVerification of Verification Process Results A B C DTest coverage of software structure (statement coverage)achievedTest coverage of software structure (decision coverage)achievedTest coverage of software structure (modifiedcondition/decision coverage) achievedAutomotive-ISO26262 –Structural coverageASIL A ASIL B ASIL C ASIL D metrics at the software unit levelStatement coverage++++++Branch coverage+++++++MC/DC (Modified Condition/Decision Coverage)+++++Reviews:Aerospace -DO-178C Applicability by SW LevelVerification of Outputs of Software Coding&Integration A B C DSource Code complies with low-level requirementsSource Code complies with software architectureSource Code is verifiableSource Code conforms to standardsSource Code is traceable to low-level requirementsSource Code is accurate and consistentOutput of software integration process is complete andcorrectAutomotive-ISO26262 –Methods for theASIL A ASIL B ASIL C ASIL D verification of software unit design andimplementationWalk-through+++o oInspection+++++++Static code analysis+++++++Formal Verification o o++Reviews:Automotive -ISO 26262 –Methods for the verification of software unit design and implementation ASIL A ASIL B ASIL C ASIL D Control flow analysis ++++++Data flow analysis++++++Aerospace -DO-178C Applicability by SW Level Verification of Verification Process Results A B C D Test coverage of software structure (data coupling and controlcoupling) achievedAerospace1.Two (!) level of Software Requirements2.Requirements based Tests on SourceCode Level (Unit Testing)!3.Normal and Robustness Tests –that’s it!4.100% Structural Test Coverage !5.DO178C is interpreted very similar in theaerospace industry.Automotive:1.Missing clear separation between functional requirements andarchitecture.2.Unit tests are written against architecture/Detailed Design and notagainst functional requirements.3.There are several Test Categories defined in the ISO26262:Requirements based testing, fault Injection test, interface test, resource usage test, back-to-back comparison between model and code.4.Many different interpretation of ISO26262 in the automotiveindustryUnit Tests considerationsComparison Aerospace and Automotive Industry Examples for different Interpretation of the Standards ToolingBest Practice AerospaceContactEffort in ReviewsAutomotive✓Failure found in Reviews are incorporated without properdocumentation of the reviewprocess.✓Content of Reviews often not properly defined(Checklists).Aerospace✓The execution of Code-,Requirements-, Design-Reviews have to be proven(Part of any audit!)=> traceable documentationof reviews and the findings isrequired.✓Checklists have to beprovided to assessors in theplanning phases of projects(Early in the project!)100% Structural Code CoverageAutomotive✓20% and more can beprovided by argumentation.✓Tests to achieve structural coverage often writtenagainst source code and notdesign and requirements.Aerospace✓ A minimum of 95% of coverage have to be achieved by tests.✓Tests to achieve structural coverage have to be writtenagainst requirements (To beproven in Audits!).Unit Tests considerationsComparison Aerospace and Automotive Industry Examples for different Interpretation of the Standards Best Practice AerospaceContactBest Practice Aerospace✓Structural Source Code Coverage ✓Requirement based Tests✓Functional Software Tests✓Traceability✓Coding guidelines✓Tool Qualification →Ideal to identify Req.-and Test weakness→80% and more structuralcoverage achieved→Proper Simulation andEmulation Test Environmentsare often sufficient→Define a strategy!→Coding strategy first! Selection of MISRA rules second!→Very good cost/benefit ratio!Contact -PublicationsContact:HEICON –Global Engineering GmbHMartin Heininger Dipl.-Ing(FH)Kreuzweg22D-88477 SchwendiTel.: +49 7353 -98 17 81Mobil: +49 176 -24 73 99 60martin.heininger@heicon-ulm.dehttp://www.heicon-ulm.dePublications:Testing power electronics according ISO26262, ATZ 04/15Monthly:Blog article about Functional Safety Topics: http://blog.heicon-ulm.de21© HEICON –Global Engineering GmbH。