tetml={filename={D:\drim\repository\projects\drim_124_0\metadata\5\a\5a46d4fcf0efbd5e49f61d02ecf4d3a1\5a46d4fcf0efbd5e49f61d02ecf4d3a1.tet.xml} elements={annotations=false bookmarks=false destinations=false fields=false javascripts = false} } granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ma INTERNATIONAL ISO STANDARD 26262-6 First edition 2011-11-15 OSS Road vehicles — Functional safety — Part 6: Product developmentat the software level Véhicules routiers — Sécurité fonctionnelle — Partie 6: Développement du produit au niveau dulogiciel SNS = Reference number | ISO 26262-6:2011(E) granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) © 180 2011 COPYRIGHT PROTECTED DOCUMENT All rights reserved. Unless otherwise specified, no part of this publication may be reproduced orutilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member bodyin the country of the requester. ISO copyright office Case postale 56 e CH-1211 Geneva 20 Tel. +41 22 74901 11 Fax +41 22 749 09 47 E-mail copyright@isv.org Web www.iso.org Published in Switzerland granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} IILl ISO 26262-6:2011(E) Contents Page FROG cuca rasosvccsevwniteusneceieisstite SMIALSGsAAACNEE bEG NN Ninmiannonnasonensnsnansasesenarsenaemmuceenansuntearumenapsromnmauseneves Vv SINECONEnissan reser voassnapdae upniteaaceiatpvnnenneanseonanenesnsonnnenmreneemmammeonswnntneunnataremtan vuvmeiaen se sybetereesvewseuesumeve creases vi A SOG ses ssnvvinonnensuanunnnnnsninesiesavuunasesiiaistecanensesoannnnceneansnanansaenneanernenusssnenyiansenuannevaviteeirtmnuneeseurssonsesveavssnvevsce 1 2 RCHRTEAEVE PERTsss nccercairzncnasraccssssiciatisetnanssnnaonnennonasnananenaneonensanannansunsemernenaananvsuununenemnviversemveeceees Z 3 Terms,definitions and abbreviated terms..............:ccsssssssesessessesescesescseessessscacsacscescsssscaceatsccececeecereeees 2 4 Requirements for COMPLIANCE. ..........csssssssssesesesssessseseseseseseseseecscscscscecscscscscecesscscesssucecscacececeaessseesensacees 2 4.1 General requirement .........cscsssssssssssceccssescsssssssssesesseseescsessesesessccessesecsecsssecessusassasacacscceasescarsecaestsatenees 2 4.2 Interpretations Of tables... .cceescesescssescssesessesecsesscscsesscsccecsecscsccacescasscsacscsassceacsusatuecacsusacaseaeeasacees 2 4.3 ASIL-dependentrequirements and recommendations.............:.:s:sscsscesessssssssceceeseseassceasescaceceaceseaces 3 5 Initiation of product developmentat the software level ..............:.:cscsssssssssescesssscescsessceecenceacesceecencess 3 5.1 ODjeCHIVES 200...eee eceeseeeeceeeeseeseeeeeesseacececsecosescescecssesseseeesseseeesesesacesscsusesscsceacessesccaseaceacerseeaceseaeeasees 3 5.2 STORIE essai seicivttinanaocrencncenneanesnensansneninromennnneennem eoremreamennancansanmienssrewecuutsananns vi kennseremupasentnanvevndnabassianrenianisiies 3 a3 INpUts tO this ClAUSE Qu... ecescseeseseeescescsceseesesscssessessessescenceaseneescenssesoessecesceesussuceessuceuceseesencesseceaseaceass 4 5.4 Requirements and recommendations. .............sscsscesscssssseessesseseccesceccesscnsesseaceascassecsesseacenseeasesaeeaceseees 4 5.5 WVOE PIOGUCES bx caserescccecczezcessciscpponceccsocenacncsnoneorsncannronssoqnaospsecsceonsoancasccsnassaessasenssaasenacaneuseenspussecenessecruner 6 6 Specification of software safety requireMeNnts..............:ccsccsscesesesseescesecsssescececscseccesceessesseaseesseeseesees 6 6.1 CERNBM sists eeivi sinsnnenrennrnenennsosenennnonsennepeenenenassensennanenaeasenananannannannnennnenensasanenannensennsennananneannenceees 6 6.2 Gee rall ............ssesescsececssssscsorscssccssccsnscescrssecscssccessorescscecscscssesscncssoncssessescscanessesesssecscaseseccescssccsesccesccsccscs 7 6.3 Inputs to this CAUSE...eee eeeceeeeeeeeensecesceesenceeseceesececesseeceseeccscecesseecensceeeneeceecanucesnaeeesesenseseesnecs 7 6.4 Requirements and recoMMendations .............csccssscssscesscesecssecesesscecseesssseseeeeeeesseeseesaueeseeeeseeceeseeseesess 7 6.5 WOFK Product.00....eee eeecsssecesseecssecescecssecesseeecseeecsseeeessecesseeesesseceseeesseseesueceseeeecseeeceeseseseseecenseseneeeeees 9 7 Software architectural M@SIGN ..............cccscessceseeessseseeescesseeeeseeceeeseenteneeeseeseeceesseeaeeeeesaeeceeseeeseeseeeeseneees 9 7.1 ODjOCHIVES 000... eeeeceteteeeeeeessssssneeeeeesesssensececeseessenaeeeeeceeeeesesauaeseseceesesaaesessceceseneuaeseesseuseneueeeeeeseneeeaaes 9 2 Gernerrall ..............scsscccssssssssccsesessssccccccccsenssnsccccccesessnsccceesessansnsceccesseceessacecsceccessesscaceccesessssecccsceseessesscccesees 9 7.3 IPPUCS COL CNIS! CLAUSvesessececers sescr secs ceicsnansanenonnsneuescdheceeseveneeabaluzebases sub ca tacna tember an aaa eseneeveseES 9 7.4 Requirenionts:and recommendations wvscsesecccczscesevversceeresssecsscscerseenearnaar aarenTTReTNE 10 7.5 WOr PROGUCTS iss sscoseossrcugsessscecassacerssarsesenersssuseatenexevacnancusaeesaszanstepesemanyencsssasscaeaven tanuacaaseseveneevesesibeeseeees 15 8 Sottwareiunit design and Implementation sicesisccscecedssecswecerccsvecsarwsvsenssavenraasesecssssscensscssesecetecsessessseve 15 8.1 0)os 15 8.2 GON Cfal ciecnvscccstacasansnsvasesewsastagesessineweswveneviteewennaaweraarausawaauvs taaueaTaceneuuesaaawesanslevanwcctvinerassunecceensensdreneeueye 15 8.3 INPULS!1O! EIS! CIAUSO sce scicscceescieesserstacssecesvasssssceeeswocessesewescecaccacwasneessscecounwepsewensussssscessavsvascsccsavescassvsccsees 16 8.4 Requirements and recommendatlon rasisssscssedecesvieerswccczecasavcccevecncovenwersewansssuccnsseveesesssecesssssacceesesseenes 16 8.5 WOPK DROGUCES ies escaiseccsscsadaauaccsanccans wwensawenss cuvsessvavenessosssosesscaveccscececstoasesvescuassuvssvousconsasconencosecarsescoransosces 18 9 SOTWaresu nit TeshNG tavaacccesaccsessc sss cweinncorecesasarensovesesaweeencdcesoevecwssevavensteveeuaucuvesatausccocervonsenmocosursveennessens 19 9.1 ODOCUUVCS are cceccasscataecassccwstan pa caseanusct ews dapencesscattaasutanaaveteveriuatuceduewessevesatuassavecervevecsecrusvedurosssvuevsseenscsnsees 19 9.2 CONCAl essiswossceveecescen ten dezeenisevavsrsavectnananieseaswsscesouuseseusvitsavavanvuaaesenccsscaceusseseusecsccceescensescscevessuarwavcanensensed 19 9.3 InpUts?to: this: ClaUSO secs cece cesreactecsrctresecscareessoesawensawecsuesusscconsecssascusacessssescuswsesssedeusesecencecscesconsdconsonscosed 19 9.4 Requirements and recommendations ...................ssssccsscccscsscsssessssscesssssnncesssncecessscsccssssecseesssssceseess 19 9.5 WONG ProdUCI iri svssevsssccticenescesttececwenatavacaseicesscasavataensassuversacsscentacecsusasossvbewoosssusateoveennsosesszecsensesenonsounesens 21 10 Softwaresinteg ravioniand KesGG :-vce sssccceccnccoressancrccccvesusecccncvesseusenesconcovscsuscoosonccncnacansscesasoassstossceten 22 10.1 ODISCTUVOS ii eventersvecscsnwsuswnseresseusvedsuh¥aessscsusecevssessereceverssararansnunjeneqsensnandst onseneeseoogsansoncanqasssianreonnsenasznasnssa 22 FO.2 Gomersrall .............cccccesesesssscscsssnessrsnsscnsncacssnssascascesccsscnccncccccccccncccancsncssanccenccnsasconccsccasccsssccussessseusscesesessesse 22 10.3 Inputs to this Clause... cece sceeeseeeeeececesceeceseeccceesesssseccesnneeesssneceeessneeeseesaeeceesausesesuseeeseeeeeesseseeees 22 10.4 Requirements and recOMMendations .............csscccecsssseeeeseneeeesseseeesssceecessseseesseneesnsseneesseeeanseessneeeas 23 10.5 Work products ............scssscssssssssssssssscssssnccsssccssccesccrssscessecccescscsssccscnsscencccssscussseusssocscscacossnccessserssscsssssaaes 25 11 Verification of software safety requirement.............cccscesessessseseessesseessseeseneeeesseeeseeneneeeeaesneseeseneees 25 granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) SE REcers ceenessnrmscenpnaremnaaeacueneiarteroasaiaiocisninenen onrensrnneenennazensennenennemrenneereerennanannnnanenerenonsvinnsarieanncuents25 TE SOTERApn ecessrsnatsrovesnneerescmen nnn vais saUatsecaACLU Aiaadsistatbicaoneonanennnandannaranerensamnnennenenancnasenasinatussertansunandl25 19.3 Inputs to Tinbes ClAUSO sseccessessiissicississestnsnensencnennsnecsnseneccoresesasecenensvenersvoensnserensuenerersensvenseatneseszeassedensvavers25 11.4 Requirements and recommendations .............scssssssesesesseseeescssesescsusecscscscscsscscscseacssacacevacenesensasaceaess26 11.5 Work products... sesseesssessssssesssssesescescseseseseesesesesessseceesesesesecsusesucecacsesacavecessscassuaceseacasacaceusavaseraresens27 AnnexA (informative) Overview of and workflow of managementof product developmentat the SOFtWare lOVEI «0.0... ceescseceseessssesscseescecessessneeeeesssesseesaeesaeesaeesseeeaeseaeesseseeeceaseeseeeseeeseesseeeseeeeeeeseseseaeees28 Annex B (informative) Model-based: development..............:.s:csscessessesssessessssssessecseeseeeeceesenscsnccasenasensenessacensees31 Annex C (normative) Software COnfiguration...............sscssssessesssscsssssessesessesscsecescenceceseceseesceesesencesensescescasenses33 Annex (informative) Freedom from interference between software elements .............:csssssseseeseeeeseeees38 EEE ere rersyormsncermmsnemneseronesevediencerrraeseasEVENS ERICTANS TELSASOSE SEROTEC SATE Seresenate!40 granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} Foreword ISO 26262-6:2011(E) ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each memberbody interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordancewith the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the memberbodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible foridentifying any or all such patentrights. ISO 26262-6 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment. ISO 26262 consists of the following parts, under the generaltitle Road vehicles — Functionalsafety: — Part 1: Vocabulary — Part 2: Managementof functional safety — Part 3: Concept phase — Part 4: Product developmentat the system level — Part 5: Product developmentat the hardware level — Part 6: Product developmentat the software level — Part 7: Production and operation — Part 8: Supporting processes — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses — Part 10: Guideline on ISO 26262 granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) Introduction ISO 26262is the adaptation of IEC 61508 to comply with needs specific to the application sector of electrical and/orelectronic (E/E) systems within road vehicles. This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components. Safety is one of the key issues of future automobile development. Newfunctionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering. Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidencethat all reasonable system safety objectives are satisfied. With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardwarefailures. ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes. System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process. Although ISO 26262 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies can be considered. ISO 26262: a) provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supportstailoring the necessary activities during these lifecycle phases; b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)]; c) uses ASILsto specify applicable requirements of ISO 26262 so as to avoid unreasonable residualrisk; d) provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved; e) provides requirements for relations with suppliers. Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the managementprocesses. Safety issues are intertwined with commonfunction-oriented and quality-oriented developmentactivities and work products. ISO 26262 addressesthe safety-related aspects of developmentactivities and work products. Figure 1 showsthe overall structure ofthis edition of ISO 26262. ISO 26262 is based upon a V-model as a reference process modelfor the different phases of product development. Within the figure: — the shaded “V’s represent the interconnection between ISO 26262-3, ISO 26262-4, ISO 26262-5, ISO 26262-6 and ISO 26262-7; — the specific clauses are indicated in the following manner: “m-n”, where “m” represents the numberof the particular part and “n” indicates the numberof the clause within that part. EXAMPLE “2-6” represents Clause 6 of ISO 26262-2. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} Z9Z9Z OSI JO MAIAIAAGC — | ainbiy 1. Vocabulary 2. Managementoffunctional safety 2-6 Safety managementduring the concept phase 2-7 Safety management after the item’s release 2-5 Overall safety management and the product development for production 3. Concept phase peel al aed): 4. Product developmentat the system level are tiation of product 4-11 Release for production : RSH 3-6Item definition pmentat the system level productiqg ee ; ieee agreReE af | ||7-6 Operation, service 3-6 Initiation of the safety lifecycle ition of the technical TEs GETTER and repair), and 3-7 Hazard analysis and risk 1 ireMents a decommissioning 3-8 Functional safety Tene ate ae concept 8-5 Interfaces within distributed developments relevel § uct ne software level a chitectural design 5-8 Evaluation of the Hardware | | Software unit design and architectural metrics AY \ tion e 5-10 Hardware inte testing 8-6 Specification and managementof safety requirements | [6-11 Verificationofsoftware safety requirements 8-13 Qualification of hardware components 8-9 Verification 8-14 Proven in use argument 9. ASIL-oriented and safety-oriented analyses 9-5 Requirements decomposition with respect to ASIL tailoring 9-7 Analysis of dependent failures 9-6 Criteria for coexistence of elements 9-8 Safety analyses 10. Guideline on ISO 26262 (3)LL0z:9-z9z9z OSI granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} INTERNATIONAL STANDARD ISO 26262-6:2011(E) Road vehicles — Functional safety — Part 6: Product developmentat the softwarelevel 1 Scope ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems andthat are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg. ISO 26262 does not address unique E/E systems in special purpose vehicles such asvehicles designedfor drivers with disabilities. Systems and their components released for production, or systems and their components already under development prior to the publication date of ISO 26262, are exempted from the scope. For further development oralterations based on systems and their components released for production prior to the publication of ISO 26262, only the modifications will be developed in accordance with ISO 26262. ISO 26262 addresses possible hazards caused ,by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems.It does not address hazardsrelatedto electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behaviour of E/E safety-related systems. ISO 26262 does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems (e.g. active and passive safety systems, brake systems, Adaptive Cruise Control). This part of ISO 26262 specifies the requirements for product development at the software level for automotive applications, including the following: — requirementsforinitiation of product developmentat the softwarelevel, — specification of the software safety requirements, — software architectural design, — software unit design and implementation, — software unit testing, — softwareintegration and testing, and — verification of software safety requirements. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document(including any amendments) applies. ISO 26262-1:2011, Road vehicles — Functional safety— Part 1: Vocabulary ISO 26262-2:2011, Road vehicles — Functional safety— Part 2: Managementof functional safety ISO 26262-4:2011, Road vehicles — Functional safety— Part 4: Product developmentat the system level ISO 26262-5:2011, Road vehicles — Functional safety— Part 5: Product developmentat the hardware level ISO 26262-8:2011, Road vehicles — Functional safety— Part 8: Supporting processes ISO 26262-9:2011, Road vehicles — Functional safety— Part 9: Automotive Safety Integrity Level (ASIL)- oriented and safety-oriented analyses 3 Terms,definitions and abbreviated terms For the purposes of this document, the terms, definitions and abbreviated terms given in ISO 26262-1:2011 apply. 4 Requirements for compliance 4.1 General requirements When claiming compliance with ISO 26262, each requirement shall be complied with, unless one of the following applies: a) tailoring of the safety activities in accordance with ISO 26262-2 has been planned and showsthat the requirement does not apply, or b) a rationale is available that the non-compliance is acceptable and the rationale has been assessed in accordance with ISO 26262-2. ; Information marked as a “NOTE” or “EXAMPLE”is only for guidance in understanding,or forclarification of the associated requirement, and shall not be interpreted as a requirementitself or as complete or exhaustive. The results of safety activities are given as work products. “Prerequisites” are information which shall be available as work products of a previous phase. Given that certain requirements of a clause are ASIL-dependent or maybetailored, certain work products may not be needed as prerequisites. “Further supporting information”is information that can be considered, but which in some casesis not required by ISO 26262 as a work product of a previous phase and which may be madeavailable by external sources that are different from the personsor organizations responsible for the functional safety activities. 4.2 Interpretations of tables Tables are normative or informative depending on their context. The different methodslisted in a table contribute to the level of confidence in achieving compliance with the corresponding requirement. Each methodin a table is either a) aconsecutive entry (marked by a sequence numberin the leftmost column, e.g. 1, 2, 3), or granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) b) an alternative entry (marked by a numberfollowedbya letter in the leftmost column, e.g. 2a, 2b, 2c). For consecutive entries, all methods shall be applied as recommended in accordance with the ASIL.If methodsother than thoselisted are to be applied, a rationale shall be given that these fulfil the corresponding requirement. For alternative entries, an appropriate combination of methods shall be applied in accordance with the ASIL indicated, independent of whether they are listed in the table or not. If methods are listed with different degrees of recommendation for an ASIL, the methods with the higher recommendation should be preferred. A rationale shall be given that the selected combination of methods complies with the corresponding requirement. NOTE A rationale based on the methodslisted in the table is sufficient. However, this does not imply a bias for or against methodsnotlisted in the table. For each method, the degree of recommendation to use the corresponding method dependson the ASIL and is categorized as follows: “++” indicates that the method is highly recommendedforthe identified ASIL; — “+” indicates that the method is recommendedforthe identified ASIL; roe — “o” indicates that the method has no recommendation for or against its usage for the identified ASIL. 4.3 ASIL-dependent requirements and recommendations The requirements or recommendations of each subclause shall be complied with for ASIL A, B, C and D, if not stated otherwise. These requirements and recommendations refer to the ASIL of the safety goal. If ASIL decomposition has been performed at an earlier stage of development, in accordance with ISO 26262-9:2011, Clause 5, the ASIL resulting from the decomposition shall be complied with. If an ASIL is given in parentheses in ISO 26262, the corresponding subclause shall be considered as a recommendation rather than a requirementfor this ASIL. This has no link with the parenthesis notation related to ASIL decomposition. 5 Initiation of product developmentat the softwarelevel 5.1 Objectives The objective of this sub-phaseis to plan andinitiate the functional safety activities for the sub-phases of the software development. 5.2 General Theinitiation of the software developmentis a planning activity, where software development sub-phases and their supporting processes (see ISO 26262-8 and ISO 26262-9) are determined and planned according to the extent and complexity of the item development. The software development sub-phases and supporting processesareinitiated by determining the appropriate methods in order to comply with the requirements and their respective ASIL. The methods are supported by guidelines and tools, which are determined and planned for each sub-phase and supporting process. NOTE Tools used for software developmentcan include tools other than softwaretools. EXAMPLE Tools used for testing phases. The planning of the software development includes the coordination with the product development at the system level (see ISO 26262-4) and the hardwarelevel (see ISO 26262-5). granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 5.3 Inputs to this clause 5.3.1 Prerequisites The following information shall be available: — projectplan (refined) in accordance with ISO 26262-4:2011, 5.5.1: — Safety plan (refined) in accordance with ISO 26262-4:201 A 52522) —_ technical safety concept in accordance with ISO 26262-4:2011, 7.5.1: — system design specification in accordance with ISO 26262-4:2011, 7.5.2; and — item integration and testing plan (refined) in accordance with ISO 26262-4:2011, 8.5.1. 5.3.2 Further supporting information The following information can be considered: — qualified software tools available (see ISO 26262-8:2011, Clause 11); — qualified software componentsavailable (see ISO 26262-8:2011, Clause 12): — design and coding guidelines for modelling and programming languages(from external source); — guidelines for the application of methods (from external source); and — guidelinesfor the application of tools (from external source). 5.4 Requirements and recommendations 5.4.1. The activities and the determination of appropriate methods for the product development at the software level shall be planned. 5.4.2 The tailoring of the lifecycle for product development at the software level shall be performed in accordance with ISO 26262-2:2011, 6.4.5, and based on the reference phase modelgivenin Figure 2. 5.4.3 If developing configurable software, Annex C shall be applied. 5.4.4 The software developmentprocessfor the software of an item, including lifecycle phases, methods, languagesandtools, shall be consistent acrossall the sub-phasesof the softwarelifecycle and be compatible with the system and hardware development phases,such that the required data can be transformed correctly. NOTE The sequencing of phases, tasks and activities, including iteration steps, for the software of an item is to ensure the consistency of the corresponding work products with the product development at the hardware level (see ISO 26262-5) and the product developmentat the system level (see ISO 26262-4). granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 2 hem testing 4-8 tern integration and ~ y Test phase testing g & venfication S 6-5 Initiation of product development at the software level Desin phase ven cation 66 Specification of software safety equirements 6-7 Software archilectyural design Software testing Test phase verification Software testing Test phase venfic ation a ite, impleme ntatio 4 phage eric ahon al — 8-10 Software integration and testing 6-11 Venfication of software safety requirements NOTE Within the figure, the specific clauses of each part of ISO 26262 areindicated in the following manner: “m-n’, where “m” represents the numberof the part and “n” indicates the numberof the clause, e.g. “4.7” represents Clause 7 of ISO 26262-4. Figure 2 — Reference phase modelfor the software development 5.4.5 For each sub-phaseof software development, the selection of the following, including guidelines for their application, shall be carried out: a) methods; and b) corresponding tools. 5.4.6 The criteria that shall be considered when selecting a suitable modelling or programming language are: . a) anunambiguousdefinition; EXAMPLE Syntax and semantics of the language. b) the support for embeddedreal time software and runtime error handling; and c) the support for modularity, abstraction and structured constructs. Criteria that are not sufficiently addressed by the languageitself shall be covered by the corresponding guidelines, or by the development environment. NOTE1_ The selected programming language (such as ADA, C, C++, Java, Assembler or a graphical modelling language) supports the topics given in 5.4.7. Programming or modelling guidelines can be used to comply with these topics. NOTE2 Assembly languages can be usedfor those parts of the software where the use of high-level programming languagesis not appropriate, such as low-level software with interfaces to the hardware, interrupt handlers,ortime-critical algorithms. ; granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 5.4.7 To support the correctnessof the design and implementation, the design and coding guidelines for the modelling, or programming languages,shall addressthetopicslisted in Table 1. NOTE 1 Coding guidelines are usually different for different programming languages. NOTE 2 Coding guidelines can be different for model-based development. NOTE3 Existing coding guidelines can be modified for a specific item development. EXAMPLE MISRA Cl] and MISRA AC AGC"are coding guidelines for the programming languageC. Table 1 — Topics to be covered by modelling and coding guidelines Enforcement of low complexity# Use of language subsets® Enforcementof strong typing Use of defensive implementation techniques Use of established design principles Use of unambiguousgraphical representation Use of style guides Use of naming conventions An appropriate compromise of this topic with other methodsin this part of ISO 26262 may be required. The objectives of method 1b are Exclusion of ambiguously defined language constructs which may be interpreted differently by different modellers, programmers, code generators or compilers. Exclusion of language constructs which from experience easily lead to mistakes, for example assignments in conditions or identical naming of local and global variables. Exclusion of language constructs which could result in unhandled run-time errors. The objective of method 1c is to imposeprinciples of strong typing where these are not inherentin the language. 5.5 Work products 5.5.1 Safety plan (refined) resulting from requirements 5.4.1 to 5.4.7. 5.5.2 Software verification plan resulting from requirements 5.4.1 to 5.4.5 and 5.4.7. 5.5.3 Design and coding guidelines for modelling and programming languages resulting from requirements 5.4.6 and 5.4.7. 5.5.4 Tool application guidelines resulting from requirements 5.4.5 and 5.4.6. 6 Specification of software safety requirements 6.1 Objectives The first objective of this sub-phase is to specify the software safety requirements. They are derived from the technical safety concept and the system design specification. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} a ISO 26262-6:2011(E) The second objective is to detail the hardware-software interface requirementsinitiated in ISO 26262-4:2011, Clause7. The third objective is to verify that the software safety requirements and the hardware-software interface requirements are consistentwith the technical safety concept and the system design specification. 6.2 General The technical safety requirements are refined and allocated to hardware and software during the system design phase given in ISO 26262-4:2011, Clause 7. The Specification of the software safety requirements considers constraints of the hardware and the impact of these constraints on the software. This sub-phase includes the specification of software Safety requirements to support the subsequent design phases. 6.3 Inputs to this clause 6.3.1 Prerequisites Thefollowing information shall be available: — technical safety concept in accordance with ISO 26262-4:2011, THA — system design specification in accordance with ISO 26262-4:2011, 7.5.2: — hardware-softwareinterface specification in accordance with ISO 26262-4:201 Ws 12520; — safety plan (refined) in accordancewith 5.5.1; — software verification plan in accordance with 5.5.2. 6.3.2 Further supporting information The following information can be considered: — hardware design specification (see ISO 26262-5:2011, (DA); — guidelinesfor the application of methods (from external source). 6.4 Requirements and recommendations 6.4.1 The software safety requirements shall address each software-based function whosefailure could lead to a violation of a technical safety requirementallocated to software. EXAMPLE Functions whosefailure could lead toa violation of a safety requirement can be: — functions that enable the system to achieve or maintain a safe state: — functionsrelated to the detection, indication and handling offaults of safety-related hardware elements: — functions related to the detection, notification and mitigation of faults in the softwareitself: NOTE 1 Theseinclude both the self-monitoring of the softwarein the operating system and application-specific self- monitoring of the softwareto detect, indicate and handle systematic faults in the application software. — functionsrelated to on-board andoff-board tests: NOTE 2 On-board tests can be carried out by the system itself or through other systems within the vehicle network during operation and during the pre-run and post-run phase ofthe vehicle. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) NOTE 3 Off-board tests refer to the testing of the safety-related functions or properties during production or in service. — functionsthat allow modifications of the software during production and service: and — functionsrelated to performance or time-critical operations. 6.4.2 The specification of the software safety requirements shall be derived from the technical safety concept and the system design in accordance with ISO 26262-4:2011, 7.4.1 and 7.4.5, and shall consider: a) the specification and management of safety requirements in accordance with ISO 26262-8:2011, Clause 6; b) the specified system and hardware configurations; EXAMPLE 1 Configuration parameters can include gain control, band pass frequencyandclock prescaler. c) the hardware-software interface specification: d) the relevant requirements of the hardware design specification; e) the timing constraints; EXAMPLE 2 Execution or reaction time derived from the required responsetime at the system level. f) the external interfaces; and EXAMPLE 3. Communication and userinterfaces. g) each operating modeofthe vehicle, the system, or the hardware, having an impact on the software. EXAMPLE 4 Operating modesof hardware devices caninclude default,initialization, test, and advanced modes. 6.4.3 If ASIL decomposition is applied to the software safety requirements, ISO 26262-9:2011, Clause 5, shall be complied with. 6.4.4 The hardware-software interface specification initiated in ISO 26262-4:2011, Clause 7, shall be detailed down to a level allowing the correct control. and usage of hardware, and shall describe each safety-related dependency between hardware and software. 6.4.5 If other functions in addition to those functions for which safety requirements are specified in 6.4.1 are carried out by the embedded software, these functions shall be specified, or else a reference madeto their specification. 6.4.6 The verification of the software safety requirements and of the refined specification of the hardware software interface shall be planned in accordance with ISO 26262-8:2011, Clause 9. 6.4.7 The refined hardware-software interface specification shall be verified jointly by the persons responsible for the system, hardware and software development. 6.4.8 The software safety requirements and the refined hardware-software interface requirements shall be verified in accordance with ISO 26262-8:2011, Clauses 6 and 9, to show their: a) b) c) compliance and consistency with the technical safety requirements; compliance with the system design; and consistency with the hardware-softwareinterface. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} 6.5 Work products ee ISO 26262-6:2011(E) 6.5.1 Software safety requirements specification resulting from requirements 6.4.1 to 6.4.3 and 6.4.5. 6.5.2 Hardware-softwareinterface specification (refined) resulting from requirement 6.4.4. NOTE This work productrefers to the same work product as given in ISO 26262-5:2011 6.5.2 6.5.3 Software verification plan (refined) resulting from requirement6.4.6. 6.5.4 Software verification report resulting from requirements 6.4.7 and 6.4.8. 7 Software architectural design 7.1 Objectives Thefirst objective of this sub-phase is to develop a software architectural design that realizes the software safety requirements. The second objective of this sub-phaseis to verify the software architectural design. 7.2 General The software architectural design represents all software components andtheir interactions in a hierarchical structure. Static aspects, such as interfaces and data paths between all software components, as well as dynamic aspects, such as process sequencesand timing behaviour are described. NOTE The software architectural design is not necessarily limited to one microcontroller or ECU, andis related to the technical safety concept and system design. The software architecture for each microcontroller is also addressed by this chapter. : In order to develop a software architectural design both software safety requirements as well as all non-safety- related requirements are implemented. Hence in this sub-phase safety-related and non-safety-related requirements are handled within one developmentprocess. The software architectural design provides the meansto implement the software safety requirements and to manage the complexity of the software development. 7.3 Inputs to this clause 7.3.1 Prerequisites The following information shall be available: — safety plan (refined) in accordance with 5.5.1: — design and coding guidelines for modelling and programming languagesin accordance with 5.5.3; — _hardware-softwareinterface specification in accordance with ISO 26262-4:2011, 7.5.3; — software safety requirements specification in accordancewith 6.5.1; — softwareverification plan (refined) in accordance with 6.5.3; and — softwareverification report in accordancewith 6.5.4. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 7.3.2 Further supporting information The following information can be considered: — technical safety concept (see ISO 26262-4:2011, 7.5.1): — system design specification (see ISO 26262-4:2011, 7.5.2); — qualified software components available (see ISO 26262-8:2011, Clause 12); — tool application guidelines in accordance with 5.5.4; and — guidelines for the application of methods (from external source). 7.4 Requirements and recommendations 7.4.1. To ensure that the software architectural design captures the information necessary to allow the subsequent developmentactivities to be performed correctly and effectively, the software architectural design shall be described with appropriate levels of abstraction by using the notations for software architectural designlisted in Table 2. Informal notations 1b | Semi-formal notations 1c Formal notations Table 2 — Notations for software architectural design Methods 7.4.2 During the developmentof the software architectural design the following shall be considered: a) theverifiability of the software architectural design; NOTE This implies bi-directional traceability between the software architectural design and the software safety requirements. b) the suitability for configurable software; c) the feasibility for the design and implementation of the software units; d) the testability of the software architecture during software integration testing; and e) the maintainability of the software architectural design. 7.4.3 In order to avoidfailures resulting from high complexity, the software architectural design shall exhibit the following properties by use of the principleslisted in Table 3: a) modularity; b) encapsulation; and c) simplicity. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} Table 3 — Principles for software architectural design Hierarchical structure of software components Restricted size of interfaces? High cohesion within each software component Restricted coupling between software components®:©: ¢ | Appropriate scheduling properties Restricted useof interrupts?4 In methods 1b, 1c, 1e and 1g "restricted" means to minimize in balance with other design considerations. ISO 26262-6:2011(E) 5 Methods 1d and1e can, for example, be achieved by separation of concernswhichrefers to the ability to identify, encapsulate, and manipulate thoseparts of software that are relevant to a particular concept, goal, task, or purpose. c Method 1e addressesthelimitation of the external coupling of software components. ¢ Any interrupts used haveto bepriority-based. NOTE An appropriate compromise between the methodslisted in Table 3 can be necessary since the methods are not mutually exclusive. 7.4.4 The software architectural design shall be developed downto the level whereall software units are identified. 7.4.5 The software architectural design shall describe: a) the static design aspects of the software components; and NOTE 1 Static design aspects address: —_ the softwarestructure includingits hierarchicallevels; — the logical sequence of data processing; — the data types andtheir characteristics; — the external interfaces of the software components; — the externalinterfaces of the software; and — the constraints including the scope of the architecture and external dependencies. NOTE 2 In the case of model-based development, modelling the structure is an inherent part of the overall modelling activities. b) the dynamic design aspects of the software components. NOTE 1 Dynamic design aspects address: — the functionality and behaviour; — the control flow and concurrency ofen — the data flow between the software components; — the data flow at external interfaces; and granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) — the temporalconstraints. NOTE 2 To determine the dynamic behaviour (e.g. of tasks, time slices and interrupts) the different operating states (e.g. power-up, shut-down, normal operation, calibration and diagnosis) are considered. NOTE 3 To describe the dynamic behaviour (e.g. of tasks, time slices and interrupts) the communication relationships andtheir allocation to the system hardware (e.g. CPU and communication channels) are specified. 7.4.6 Every safety-related software componentshall be categorized as oneofthe following: a) newly developed; b) reused with modifications; or Cc) reused without modifications. 7.4.7 Safety-related software components that are newly developed or reused with modifications shall be developedin accordance with ISO 26262. NOTE In these cases ISO 26262-8:2011, Clause 12, does not apply. 7.4.8 Safety-related software components that are reused without modifications shall be qualified in accordancewith ISO 26262-8:2011, Clause 12. NOTE The use of qualified software components does not affect the applicability of Clauses 10 and 11. However, someactivities described in Clauses 8 and 9 can be omitted. 7.4.9 The software safety requirements shall be allocated to the software components. As a result, each software component shall be developed in compliance with the highest ASIL of any of the requirements allocatedto it. NOTE Followingthis allocation, further refinementof the software safety requirements can be necessary. 7.4.10 If the embedded software has to implement software componentsofdifferent ASILs, or safety-related and non-safety-related software components, then all of the embedded software shall be treated in accordance with the highest ASIL, unless the software components meet the criteria for coexistence in accordance with ISO 26262-9:2011, Clause 6. 7.4.11 If software partitioning (see Annex D) is used to implement freedom from interference between software componentsit shall be ensured that: a) the shared resources are used in such a way that freedom from interference of software partitions is ensured; NOTE 1 Taskswithin a software partition are not free from interference among eachother. NOTE 2 One software partition cannot change the code or data of another software partition nor command non- shared resourcesof other software partitions. NOTE 3 The service received from shared resources by one software partition cannot be affected by another software partition. This includes the performance of the resources concerned,as well as the rate, latency,jitter and duration of scheduled accessto the resource. b) the software partitioning is supported by dedicated hardware features or equivalent means(this requirement applies to ASIL D, in accordance with 4.3); c) the part of the software that implements the software partitioning is developed in compliance with the same or an ASIL higher than the highest ASIL assigned to the requirements of the software partitions; and granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} NOTE In general the operating system provides or supports software partitioning. “ee Le ISO 26262-6:2011(E) d) the verification of the software partitioning during software integration and testing (in accordance with Clause 10) is performed. 7.4.12 An analysis of dependentfailures in accordance with ISO 26262-9:2011, Clause 7, shall be carried out if the implementation of software safety requirements relies on freedom from interference or sufficient independence between software components. 7.4.13 Safety analysis shall be carried out at the software architectural level in accordance with ISO 26262-9:2011, Clause 8, in orderto: — identify or confirm the safety-related parts of the software; and — support the specification and verify the efficiency of the safety mechanisms. NOTE Safety mechanismscan be specified to cover both issues associated with random hardwarefailures as well as softwarefaults. 7.4.14 To specify the necessary software safety mechanismsat the software architectural level, based on the results of the safety analysis in accordance with 7.4.13, mechanisms for error detection aslisted in Table 4 shall be applied. NOTE Whennotdirectly required by technical safety requirements allocated to software, the use of software safety mechanismsis reviewedat the system level to analyse the potential impact on the system behaviour. la 1b Plausibility check? 1c | 1d Table 4 — Mechanismsforerror detection at the software architectural level Range checksof input and output data Detection of data errors? External monitoring facility© Methods 1e | Control flow monitoring | Oo | 1f aber Diverse software design 4 Plausibility checks can include using a reference model of the desired behaviour, assertion checks, or comparing signals from different sources. b Types of methods that may be usedto detect data errors include error detecting codes and multiple data storage. ¢ Anexternal monitoring facility can be, for example, an ASIC or another software element performing a watchdogfunction. 7.4.15 This subclause applies to ASIL (A), (B), C and D, in accordance with 4.3: to specify the necessary software safety mechanismsat the software architectural level, based on the results of the safety analysis in accordancewith 7.4.13, mechanismsfor error handling aslisted in Table 5 shall be applied. NOTE 1 Whennotdirectly required by technical safety requirements allocated to software, the use of software safety mechanismsis reviewed at the system level to analyse the potential impact on the system behaviour. NOTE2 The analysis at software architecturallevel of possible hazards due to hardware is described in ISO 26262-5. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) Table 5 — Mechanismsforerror handling at the software architectural level Static recovery mechanism# Graceful degradation® Independentparallel redundancy® Correcting codesfor data Methods # Static recovery mechanisms can include the use of recovery blocks, backward recovery, forward recovery and recovery through repetition. 5 Graceful degradation at the software level refers to prioritizing functions to minimize the adverse effects of potential failures on functional safety. c Independent parallel redundancycan berealized as dissimilar software in each parallel path. 7.4.16 If new hazards introduced by the software architectural design are not already covered by an existing safety goal, they shall be introduced and evaluated in the hazard analysis and risk assessmentin accordance with the change managementprocessin ISO 26262-8:2011, Clause 8. NOTE Newly identified hazards, not already reflected in a safety goal, are usually non-functional hazards. If those non-functional hazards are outside the scopeof this standard thenit is recommended that they be annotated in the hazard analysis and risk assessmentwith the following statement “No ASIL is assigned to this hazard asit is not within the scope of ISO 26262.” However, an ASILis allowed for reference purposes. 7.4.17 An upperestimation of required resources for the embeddedsoftware shall be made,including: a) the execution time; b) the storage space; and EXAMPLE RAMfor stacks and heaps, ROM for program and non-volatile data. c) the communication resources. ! 7.4.18 The software architectural design shall be verified in accordance with ISO 26262-8:2011, Clause 9, and by using the software architectural design verification methods listed in Table 6 to demonstrate the following properties: a) compliance with the software safety requirements; b) compatibility with the target hardware; and NOTE This includes the resources as specified in 7.4.17. c) adherenceto design guidelines. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} Table 6 — Methodsforthe verification of the software architectural design Walk-through of the design@ Inspection of the design? Methods Simulation of dynamicparts of the design® | Prototype generation oO | Formalverification 1 | Control flow analysis® Data flow analysis® In the case of model-based development these methods can be applied to the model. Method 1c requires the usage of executable models for the dynamic parts of the software architecture. Control and dataflow analysis may belimited to safety-related componentsandtheir interfaces. 7.5 Work products ++ + + | oO ISO 26262-6:2011(E) 7.5.1 Software architectural design specification resulting from requirements 7.4.1 to 7.4.6, 7.4.9, 7.4.10, 7.4.14, 7.4.15 and 7.4.17. 7.5.2 Safety plan (refined) resulting from requirement 7.4.7. 7.5.3 Software safety requirements specification (refined) resulting from requirement 7.4.9. 7.5.4 Safety analysis report resulting from requirement 7.4.13. 7.5.5 Dependentfailures analysis report resulting from requirement 7.4.12. 7.5.6 Software verification report (refined) resulting from requirement 7.4.18. 8 Software unit design and implementation 8.1 Objectives The first objective of this sub-phase is to specify the software units in accordance with the software architectural design and the associated software safety requirements. The second objective of this sub-phaseis to implement the software units as specified. The third objective of this sub-phaseis the static verification of the design of the software units and their implementation. 8.2 General Based on the software architectural design, the detailed design of the software units is developed. The detailed design will be implemented as a model or directly as source code, in accordance with the modelling or coding guidelines respectively. The detailed design and the implementation are statically verified before proceeding to the software unit testing phase. The implementation-related properties are achievable at the source code level if manual code development is used. If model-based development with automatic code generation is used, these properties apply to the model and need notapply to the source code. In order to develop a single software unit design both software safety requirements as well as all non-safety- related requirements are implemented. Hence in this sub-phase safety-related and non-safety-related requirements are handled within one developmentprocess. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) The implementation of the software units includes the generation of source code and the translation into object code. 8.3 Inputs to this clause 8.3.1 Prerequisites The following information shall be available: — design and coding guidelines for modelling and programming languagesin accordance with 5.5.3; — softwareverification plan (refined) in accordance with 6.5.3: — softwarearchitectural design specification in accordance with 7.5.1: — safety plan (refined) in accordance with 7.5.2: — software safety requirements specification (refined) in accordance with 7.5.3; and — software verification report (refined) in accordance with 7.5.6. 8.3.2 Further supporting information The following information can be considered: — technical safety concept (see ISO 26262-4:2011, 7.5.1); — system design specification (see ISO 26262-4:2011, 7.5.2): — tool application guidelines in accordance with 5.5.4: — _hardware-softwareinterface specification (refined) (see 6.5.2); — safety analysis report in accordance with 7.5.4; and — guidelines for the application of methods (from external source). 8.4 Requirements and recommendations 8.4.1 The requirementsof this subclause shall be complied with if the softwareunit is safety-related. NOTE “Safety-related” meansthat the unit implements safety requirements, or that the criteria for coexistence (see ISO 26262-9:2011, Ciause 6) of the unit with other units are not satisfied. 8.4.2 To ensure that the software unit design captures the information necessary to allow the subsequent developmentactivities to be performed correctly and effectively, the software unit design shall be described using the notationslisted in Table 7. Natural language 1b Informal notations Semi-formal notations Formal notations Table 7 — Notations for software unit design granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) NOTE In the case of model-based development with automatic code generation, the methods for representing the software unit design are applied to the model which servesasthe basis for the code generation. 8.4.3. The specification of the software units shall describe the functional behaviour and the internal design to the level of detail necessary for their implementation. EXAMPLE Internal design can include constraints on the use of registers and storageof data. 8.4.4 Design principles for software unit design and implementation at the source code level as listed in Table 8 shall be applied to achieve the following properties: a) correct order of execution of subprograms and functions within the software units, based on the software architectural design; consistency of the interfaces between the software units; correctnessof data flow and control flow between andwithin the software units; simplicity; readability and comprehensibility; robustness; EXAMPLE Methodsto prevent implausible values, execution errors, division by zero, and errors in the data flow and controlflow. suitability for software modification; and testability. Table 8 — Design principles for software unit design and implementation Methods Oneentry and oneexit point in subprograms and functions# No dynamic objects or variables, or else online test during their creation#.> Initialization of variables No multiple use of variable names? Avoid global variablesor elsejustify their usage® Limited use of pointers No implicit type conversions? No hidden data flow or control flow” No unconditional jumps#:>.° | No recursions Methods1a, 1b, 1d, 1e, 1f, 1g and 1i may not be applicable for graphical modelling notations used in model-based development. Methods 1g and 1i are not applicable in assembler programming. ! : Methods 1h and 1i reduce the potential for modelling data flow and control flow through jumpsorglobal variables. NOTE For the C language, MISRA CIS! covers many of the methodslisted in Table 8. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 8.4.5 The software unit design and implementation shall be verified in accordance with ISO 26262-8:2011 Clause 9, and by applying the verification methodslisted in Table 9, to demonstrate: a) the compliance with the hardware-software interface specification (in accordance with ISO 26262-5:2011, 6.4.10): b) the fulfilment of the software safety requirements as allocated to the software units (in accordance with 7.4.9) through traceability; c) the complianceof the source codewith its design specification; NOTE In the case of model-based development, requirement C) still applies. d) the compliance of the source code with the coding guidelines (see 5.5.3); and €) the compatibility of the software unit implementations with the target hardware. Table 9 — Methodsforthe verification of software unit design and implementation Walk-through? | : Inspection? Semi-formalverification Formal verification Controlflow analysis®.© Data flow analysis®.° 1g |Static codeanalysis Semantic code analysis9 Methods 3 In the case of model-based software developmentthe software unit specification design and implementation can beverified at the modellevel. 5 Methods te and 1f can be applied at the source code level. These methods are applicable both to manual code development and to model-based development. ° Methods1e and 1f can be part of methods 1d, 1g or th. d Method 1h is used for mathematical analysis of source code by use of an abstract representation of possible values for the variables. Forthis it is not necessary to translate and execute the source code. NOTE Table lists only static verification techniques. Dynamic verification techniques (e.g. testing techniques) are covered in Tables 10, 11 and 12. 8.5 Work products 8.5.1. Software unit design specification resulting from requirements 8.4.2 to 8.4.4. NOTE In the case of model-based development, the implementation model and supporting descriptive documentation, using techniqueslisted in Table 8, specifies the software units. 8.5.2 Software unit implementation resulting from requirement 8.4.4. 8.5.3. Software verification report (refined) resulting from requirement 8.4.5. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} 9 Software unit testing 9.1 Objectives ISO 26262-6:2011(E) The objective of this sub-phase is to demonstrate that the software units fulfil the software unit design specifications and do not contain undesired functionality. 9.2 General A procedure for testing the software unit against the software unit design specificationsis established, and the tests are carried out in accordance with this procedure. 9.3 Inputs to this clause 9.3.1 Prerequisites The following information shall be available: — hardware-software interface specification (refined) in accordance with 6.5.2; — software verification plan (refined) in accordance with 6.5.3; — safety pian (refined) in accordance with 7.5.2: — software unit design specification in accordance with 8.5.1; — software unit implementation in accordance with 8.5.2; and — software verification report (refined) in accordancewith 8.5.3. 9.3.2 Further supporting information The following information can be considered: — tool application guidelines in accordance with 5.5.4; and — guidelinesfor the application of methods (from external source). 9.4 Requirements and recommendations 9.4.1. The requirementsof this subclause shall be complied with if the software unit is safety-related. NOTE “Safety-related” meansthat the unit implements safety requirements, orthat the criteria for coexistence of the unit with other units are not satisfied. 9.4.2 Software unit testing shall be planned, specified and executed in accordancewith ISO 26262-8:2011, Clause 9. NOTE 1 Based on thedefinitions in ISO 26262-8:2011, Clause 9, the test objects in the software unit testing are the software units. NOTE 2. For model-based software development, the correspondingparts of the implementation model also represent objects for the test planning. Depending on the selected software developmentprocess the test objects can be the code derived from this model or the modelitself. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 9.4.3 The software unit testing methodslisted in Table 10 shall be applied to demonstrate that the software units achieve: a) compliance with the software unit design specification (in accordance with Clause8): b) compliance with the specification of the hardware-software interface (in accordance with ISO 26262-5:2011, 6.4.10); c) the specified functionality; d) confidence in the absence of unintended functionality; e) robustness; and EXAMPLE The absence of inaccessible software, the effectiveness of error detection and error handling mechanisms. f) sufficient resources to support their functionality. 1a | Requirements-basedtest? Interface test | Fault injection test® | Resource usagetest® Table 10 — Methodsfor software unit testing Back-to-back comparison test between model and code,if applicable? a Thesoftware requirements at the unit level are the basis for this requirements-basedtest. > This includes injection of arbitrary faults (e.g. by corrupting values of variables, by introducing code mutations, or by corrupting values of CPU registers). © Someaspects of the resource usagetest can only be evaluated: properly when the software unit tests are executed on the target hardwareor if the emulator for the target processor supports resource usagetests. 3 This method requires a model that can simulate the functionality of the software units. Here, the model and codearestimulated in the same way and results compared with each other. 9.4.4 To enable the specification of appropriate test cases for the software unit testing in accordance with 9.4.3, test cases shall be derived using the methodslisted in Table 11. Analysis of requirements Table 11 — Methodsfor deriving test cases for software unit testing Methods Generation and analysis of equivalence classes@ | Analysis of boundary values? Error guessing® @ Equivalence classes can beidentified based on the division of inputs and outputs, such that a representative test value can be selected for each class. 5 This method applies to interfaces, values approaching and crossing the boundaries and out of range values. © Error guessing tests can be based on data collected through a “lessons learned” process and expert judgment. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 9.4.5 To evaluate the completeness of test cases and to demonstrate that there is no unintended functionality, the coverage of requirements at the software unit level shall be determined and the structural coverage shall be measured in accordance with the metrics listed in Table 12. If the achieved structural coverage is considered insufficient, either additional test cases shall be specified or a rationale shall be provided. EXAMPLE1 Analysis of structural coverage can reveal shortcomings in requirement-based test cases, inadequacies in requirements, dead code, deactivated code or unintended functionality. EXAMPLE2 A rationale can be given for the level of coverage achieved based on accepted dead code(e.g. code for debugging) or code segments depending on different software configurations; or code not covered can beverified using complementary methods(e.g. inspections). Statement coverage Branch coverage Table 12 — Structural coverage metrics at the software unitlevel Methods MC/DC (Modified Condition/Decision Coverage) NOTE 1 Thestructural coverage can be determined by the use of appropriate softwaretools. NOTE 2 In the case of model-based development, the analysis of structural coverage can be performed at the model level using analogousstructural coverage metrics for models. NOTE 3 If instrumented code is used to determine the degree of coverage, it can be necessary to show that the instrumentation has no effect on the test results. This can be done by repeating the tests with non-instrumented code. 9.4.6 The test environment for software unit testing shall correspond as closely as possible to the target environment. If the software unit testing is not carried out in the target environment, the differences in the source and object code, and the differences between the test environment and the target environment, shall be analysed in orderto specify additional tests in the target environment during the subsequenttest phases. NOTE1 Differences between the test environment and the target environment can arise in the source code or object code, for example, due to different bit widths of data words and address wordsof the processors. NOTE 2 Depending on the scopeofthetests, the appropriate test environmentfor the execution of the software unit is used (e.g. the target processor, a processor emulator or a development system). NOTE3 Softwareunit testing can be executed in different environments,for example: — model-in-the-looptests; — software-in-the-loop tests; — processor-in-the-loop tests; and — __hardware-in-the-looptests. NOTE 4 For model-based development, software unit testing can be carried out at the modellevelfollowed by back-to- back comparison tests between the model and the object code. The back-to-back comparison tests are used to ensure that the behaviour of the models with regard to the test objectives is equivalentto the automatically-generated code. 9.5 Work products 9.5.1 Software verification plan (refined) resulting from requirements 9.4.2 to 9.4.6. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 9.5.2 Softwareverification specification resulting from requirements 9.4.2 and 9.4.4 to 9.4.6. 9.5.3 Software verification report (refined) resulting from requirement 9.4.2. 10 Software integration and testing 10.1 Objectives Thefirst objective of this sub-phaseis to integrate the software elements. The second objective of this sub-phase is to demonstrate that the software architectural design is realized by the embedded software. 10.2 General In this sub-phase, the particular integration levels and the interfaces between the software elements are tested against the software architectural design. The steps of the integration and testing of the software elements corresponddirectly to the hierarchical architecture of the software. The embeddedsoftware canconsistof safety-related and non-safety-related software elements. 10.3 Inputs to this clause 10.3.1 Prerequisites The following information shall be available: — hardware-softwareinterface specification (refined) in accordance with 6.5.2: — software architectural design specification in accordance with 7.5.1: — safety plan (refined) in accordance with 7.5.2: — software unit implementation in accordance with 8.5.2: — softwareverification plan (refined) in accordancewith 9.5.1; — software verification specification in accordance with 9.5.2; and — software verification report (refined) in accordance with 9.5.3. 10.3.2 Further supporting information The following information can be considered: — qualified software components available (see ISO 26262-8:2011, Clause 12); — software tool qualification report in accordance with ISO 26262-8:2011, 11.5.2: — tool application guidelines in accordance with 5.5.4; and — guidelinesfor the application of methods (from external source). granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} 10.4 Requirements and recommendations ISO 26262-6:2011(E) 10.4.1 The planning of the software integration shall describe the steps for integrating the individual software units hierarchically into software components until the embedded software is fully integrated, and shall consider: a) the functional dependencies that are relevant for software integration; and b) the dependencies betweenthe softwareintegration and the hardware-software integration. NOTE For model-based development, the software integration can be replaced with integration at the modellevel and subsequent automatic code generation from the integrated model. 10.4.2 Software integration testing shall be planned, specified and executed in accordance with ISO 26262-8:2011, Clause 9. NOTE1 Based onthe definitions in ISO 26262-8:2011, Clause 9, the software integration test objects are the software components. NOTE 2 For model-based development, the test objects can be the models associated with the software components. 10.4.3. The software integration test methodslisted in Table 13 shall be applied to demonstrate that both the software components and the embeddedsoftware achieve: a) compliance with the software architectural design in accordance with Clause 7; b) compliance with the specification of the hardware-software interface in accordance with ISO 26262-4:2011, Clause 7; c) the specified functionality; d) robustness; and EXAMPLE Absenceof inaccessible software; effective error detection and handling. e) sufficient resources to support the functionality. Requirements-basedtest® Interface test | Fault injection test® Resource usagetest Table 13 — Methodsfor software integration testing Back-to-back comparison test between modeland code, if applicable® The software requirements at the architectural level are the basis for this requirements-basedtest. This includesinjection of arbitrary faults in order to test safety mechanisms(e.g. by corrupting software or hardware components). © To ensure the fulfilment of requirements influenced by the hardware architectural design with sufficient tolerance, properties such as average and maximum processor performance, minimum or maximum execution times, storage usage (e.g. RAM for stack and heap, ROMfor program and data) and the bandwidth of communication links (e.g. data buses) have to be determined. 3 Someaspects of the resource usage test can only be evaluated properly when the softwareintegration tests are executed on the target hardwareorif the emulator for the target processor supports resource usagetests. € This method requires a model that can simulate the functionality of the software components. Here, the model and code are stimulated in the same way and results compared with each other. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 10.4.4 To enable the specification of appropriate test cases for the software integration test methods selected in accordance with 10.4.3, test cases shall be derived using the methodslisted in Table 14. Table 14 — Methodsfor deriving test cases for software integration testing Analysis of requirements Methods 1b | Generation ana analysis of equivalence classes# Analysis of boundary values® Error guessing® @ Equivalence classes can be identified based on the division of inputs and outputs, such that a representative test value can be selected for each class. 5 This method applies to parameters or variables, values approaching and crossing the boundaries and out of range values. © Error guessing tests can be based on data collected through a “lessons learned” process and expert judgment. 10.4.5 To evaluate the completeness of tests and to obtain confidence that there is no unintended functionality, the coverage of requirements at the software architectural level by test cases shall be determined. If necessary, additional test cases shall be specified or a rationale shall be provided. 10.4.6 This subclause applies to ASIL (A), (B), C and D, in accordance with 4.3: To evaluate the completenessof test cases andto obtain confidence that there is no unintended functionality, the stiuctural coverage shall be measured in accordance with the metrics listed in Table 15. If the achieved structural coverage is considered insufficient, either additional test cases shall be specified or a rationale shall be provided. EXAMPLE Analysis of structural coverage can reveal shortcomings in the requirement-based test cases, inadequacies in the requirements, dead code, deactivated code or unintended functionality. Table 15 — Structural coverage metrics at the software architecturallevel 4 Method 1a refers to the percentage of executed software functions. This evidence can be achieved by an appropriate software integration strategy. 5b Method 1brefers to the percentage of executed software function. calls. NOTE1_ Thestruciural coverage can be determined using appropriate softwaretools. NOTE2 In the case of model-based development, software architecture testing can be performedat the modellevel using analogousstructural coverage metrics for models. 10.4.7 It shall be verified that the embedded softwarethatis to be included as part of a production release in accordance with ISO 26262-4:2011, Clause 11, contains all the specified functions, and only contains other unspecified functionsif these functions do not impair the compliance with the software safety requirements. EXAMPLE In this context unspecified functions include code used for debugging or instrumentation. NOTE If deactivation of these unspecified functions can be ensured, this is an acceptable means of compliance with this requirement. Otherwise the removalof such codeis a change (see ISO 26262-8:2011, Clause 8). granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) 10.4.8 The test environment for software integration testing shall correspond as closely as possible to the target environment. If the software integration testing is not carried out in the target environment, the differences in the source and object code and the differences between the test environment and the target environment shall be analysed in order to specify additional tests in the target environment during the subsequenttest phases. NOTE1 Differences between the test environment and the target environment canarise in the source or object code, for example, dueto different bit widths of data words and address wordsof the processors. NOTE2 Depending on the scope of the tests and the hierarchical level of integration, the appropriate test environmentsfor the execution of the software elements are used. Such test environments can be the target processorfor final integration, or a processor emulator or a development system for the previous integration steps. NOTE 3 Software integration testing can be executedin different environments, for example: — model-in-the-loop tests; — software-in-the-loop tests; — processor-in-the-loop tests; and — hardware-in-the-looptests. 10.5 Work products 10.5.1 Software verification plan (refined) resulting from requirements 10.4.1 to 10.4.6 and 10.4.8. 10.5.2 Software verification specification (refined) resulting from requirements 10.4.1, 10.4.2, 10.4.4, 10.4.5, 10.4.7 and 10.4.8. 10.5.3 Embeddedsoftwareresulting from requirement 10.4.1. 10.5.4 Software verification report (refined) resulting from requirement 10.4.2. 11 Verification of software safety requirements 11.1 Objectives The objective of this sub-phase is to demonstrate that the embedded software fulfils the software safety requirements. 11.2 General The purpose of the verification of the software safety requirements is to demonstrate that the embedded software satisfies its requirements in the target environment. 11.3 Inputs to this clause 11.3.1 Prerequisites The following information shall be available: — software architectural design specification in accordance with 7.5.1; — safety plan (refined) in accordancewith 7.5.2; — software safety requirements specification (refined) in accordance with 7.5.3; granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) — softwareverification plan (refined) in accordance with 10.5.1: — softwareverification specification (refined) in accordance with 10.5.2; — softwareverification report (refined) in accordance with 10.5.4; and — integration testing report in accordance with ISO 26262-4:201 1,:8:5:3. 11.3.2 Further supporting information The following information can be considered: — validation plan (refined) (see ISO 26262-4:2011, 6.5.3); — technical safety concept (see ISO 26262-4:2011, C551); — system design specification (see ISO 26262-4:2011, Gd?) — tool application guidelines in accordance with 5.5.4: and — guidelines for the application of methods (from external source). 11.4 Requirements and recommendations 11.4.1 The verification of the software safety requirements shall be planned, specified and executed in accordancewith ISO 26262-8:2011, Clause 9. 11.4.2 To verify that the embeddedsoftwarefulfils the software safety requirements, tests shall be conducted in the test environmentslisted in Table 16. NOTE Test casesthat already exist, for example from software integration testing, can be re-used. Tabie 16 — Test environments for conducting the software safety requirements verification Hardware-in-the-loop Electronic control unit network environments? Vehicles @ Examplesinclude test benches partially or fully integrating the electrical systems of a vehicle, “lab-cars” or “mule” vehicles, and “rest of the bus” simulations. 11.4.3 The testing of the implementation of the software safety requirements shall be executed on the target hardware. 11.4.4 Theresults of the verification of the software safety requirements shall be evaluated with regardto: a) compliance with the expected results; b) coverageof the software safety requirements; and C) passorfail criteria. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} 11.5 Work products 11.5.1 Software verification plan (refined) resulting from requirements 11.4.1 to 11.4.3. ISO 26262-6:2011(E) 11.5.2 Software verification specification (refined) resulting from requirements 11.4.1 to 11.4.3. 11.5.3 Software verification report (refined) resulting from requirements 11.4.1 and 11.4.4. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) Annex A (informative) Overview of and workflow of managementof product developmentat the softwarelevel Table A.1 provides an overview of objectives, prerequisites and work products of the particular phases of the product developmentat the softwarelevel. fan of product development at the software level 6 Specification of software safety requirements 7 Software architectural design Table A.1 — Overview of product developmentat the software level Plan andinitiate the functional Project plan (refined) 5.5.1 Safety plan (refined) safety activities for the (see ISO 26262-4:2011, 5.5.1) ' ; sub-phasesof the software ‘ 5.5.2 Softwareverification plan devel t activity. Safety plan (refined) aay (see ISO 26262-4:2011, 5.5.2) Specify software safety requirements. The software safety requirements are derived from the technical safety concept and the system design specification. Detail the hardware-software interface requirements. Verify that the software safety requirements and the hardware-softwareinterface requirements are consistent with the technical safety concept and the system design specification. Develop a software architectural design that realizes the software safety requirements. Verify the software architectural Technical safety concept (see ISO 26262-4:2011, 7.5.1) System design specification (see ISO 26262-4:2011, 7.5.2) Item integration and testing plan (refined) (see ISO 26262-4:2011, 7.5.4) Technical safety concept (see ISO 26262-4:2011, 7.5.1) System design specification (see ISO 26262-4:2011, 7.5.2) Hardware-software interface specification (see ISO 26262-4:2011, 7.5.6) Safety plan (refined) (see 5.5.1) Softwareverification plan (see 5.5.2) Safety plan (refined) (see 5.5.1) Design and coding guidelines for modelling and programming languages(see 5.5.3) design. | Hardware-software interface | specification (see ISO 26262-4:2011, 7.5.6) Software safety requirements 5.5.3 Design and coding guidelines for modelling and programming languages 5.5.4 Tool application guidelines 6.5.1 Software safety requirements specification 6.5.2 Hardware-software interface specification (refined) 6.5.3 Software verification plan (refined) 6.5.4 Software verification report 7.5.1 Software architectural design specification 7.5.2 Safety plan (refined) 7.5.3 Software safety requirements specification (refined) 7.5.4 Safety analysis report specification (see 6.5.1) 7.5.5 Dependentfailures analysis Software verification plan (refined) (see 6.5.3) Software verification report (refined) (see 6.5.4) report 7.5.6 Software verification report (refined) granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} slices unit design and implementa- tion 9 Softwareunit testing integration andtesting 11 Verification of software safety requirements Specify the software unitsin accordancewith the software architectural design and the associated software safety requirements. Implement the software units as specified. Static verification of the software unit design and their implementation. Demonstrate that the software units fulfil the software unit design specifications and do not contain undesired functionality. Integrate the software elements. Demonstrate that the software architectural design is realized by the embeddedsoftware. Demonstrate that the embedded softwarefulfils the software safety requirements. Table A.1 (continued) ISO 26262-6:2011(E) Design and coding guidelines for 8.5.1 Software unit design modelling and programming specification anguayeS see Oo) 8.5.2 Software unit Softwareverification plan (refined) (see 6.5.3) implementation Software architectural design (refined) specification (see 7.5.1) Safety plan (refined) (see 7.5.2) Software safety requirements specification (refined) (see 7.5.3) Software verification report (refined) (see 7.5.6) Hardware-software interface specification (refined) (see 6.5.2) Software verification plan (refined) (see 6.5.3) Safety plan (refined) (see 7.5.2) 8.5.3 Software verification report 9.5.1 Software verification plan (refined) 9.5.2 Software verification specification Software unit design specification Cement (see 8.5.1) Software unit implementation (see 8.5.2) Software verification report (refined) (see 8.5.3) Hardware-software interface specification (refined) (6.5.2) Software architectural design specification (see 7.5.1) Safety plan (refined) (see 7.5.2) Software unit implementation (see 8.5.2) Software verification plan (refined) (see 9.5.1) Softwareverification specification (refined) (see 9.5.2) Software verification report (refined) (see 9.5.3) Software architectural design specification (see 7.5.1) Safety plan (refined) (see 7.5.2) Software safety requirements 9.5.3 Software verification report 10.5.1 Software verification plan (refined) 10.5.2 Softwareverification specification (refined) 10.5.3 Embedded software 10.5.4 Softwareverification report (refined) 11.5.1 Software verification plan (refined) 11.5.2 Software verification specification (refined) specification (refined) (see 7.5.3) 11.5.3 Software verification report fined Software verification plan (refined) irene) (see 10.5.1) Software verification specification (refined) (see 10.5.2) Software verification report (refined) (see 10.5.4) Integration testing report (see ISO 26262-4:2011, 8.5.2) granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) Table A.1 (continued) Annex C Enable controlled changesin the See applicable prerequisites of behaviour of the software for the relevant.phasesof the safety configuration different applications lifecycle in which software configuration is applied. Work products C.5.1 Configuration data specification C.5.2 Calibration data specification C.5.3 Safety plan (refined) C.5.4 Configuration data C.5.5 Calibration data C.5.6 Software verification plan (refined) C.5.7 Verification specification C.5.8 Verification report granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} B.1 Objectives Annex B (informative) Model-based development ISO 26262-6:2011(E) This annex describes the concept of model-based development of in-vehicle software and outlines its implications on the product developmentat the softwarelevel. B.2 General Mathematical modelling, which has been extensively used in many engineering domains, is also gaining widespread use in the development of embedded software. In the automotive sector, modelling is used for the conceptual capture of the functionality to be realized (open/closed loop control, monitoring) as well as for the simulation of real physical system behaviours (vehicle environment). Modelling is usually carried out with commercial off-the-shelf modelling and simulation software tools. They support the developmentand definition of system/software elements, and their connections and interfaces by semi-formal graphical models. These models employ editable, hierarchical block diagrams (e.g. control diagrams) and extended state transition diagrams (e.g. state charts). The software tools provide the necessary meansof description, computation techniques and interpreters/compilers. Graphical editors permit an intuitive development and description of complex models. Hierarchically structured modularity is used in order to control complexity. A model consists of function blocks with well-defined inputs and outputs. Function blocks are connected within the block diagram by directed edges between their interfaces, which describe signal flows. With this, they represent equations in the mathematical model, which relate the interface variables of different elements. The connection lines represent causally motivated directions of action, which define the outputs of one block as the inputs of another. Other tool-specific modelling semantics also can be used to impose order of execution and timing. The hierarchy of elements can contain several levels of refinement. Such models can be simulated, i.e. executed. During simulation the calculation causality follows the defined directions of action until the entire model has been processed. There is a range ofdifferent solvers available for solving the equations described by the model. Variable-step solvers are used primarily for modelling the vehicle and the environment. For the development of embedded software, fixed-step solvers are used, which represent a necessary prerequisite for efficient code generation. The modelling style described is used extensively within the scope of model-based development of embedded in-vehicle software. Typically, both an executable modelof the control software (e.g. a functional model) and a model of the surrounding system (e.g. a vehicle model) and its environment(e.g. an environment model) are created early in the development cycle and are simulated together. This way, it is possible to model even highly complex automotive systems with a high degree of detail at an acceptable calculation speed and to simulate their behaviour close to reality. While the vehicle/environment modelis gradually replaced during the course of development by the real system and its real environment, the functional model can serve as a blueprint for the implementation of embedded software on the control unit through code generation. One characteristic of the model-based development paradigm is the fact that the functional model not only specifies the desired function but also provides design information and finally even serves asthe basis of the implementation by means of code generation. In other words, such a functional model represents specification aspects as well as design and implementation aspects. In practice, these different aspects are reflected in an evolution of the functional model from an early specification model via a design model to an implementation model and finally its automatic transformation into code (model evolution). In comparison to code-based software developmentwith a clear separation of phases, in model-based developmenta stronger coalescence granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) of the phases “Software safety requirements”, “Software architectural design” and “Software unit design and implementation” can be noted. Moreover, one and the same graphical modelling notation is used during the consecutive development stages. Verification activities can also be treated differently since models can be used as a useful source of information for the testing process (e.g. model-based testing), or can serve as the object to be verified. The seamlessutilization of models facilitates highly consistent and efficient development. NOTE The paradigm of model-based development does not depend on the existence of the model type mentioned above. Alternative models such as UML can beused. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} C.1 Objectives Annex C (normative) Software configuration ISO 26262-6:2011(E) The objective of software configuration is to enable controlled changes in the behaviour of the software for different applications. C.2 General description Configurable software enables the development of application specific software using configuration and calibration data (see Figure C.1). C.3 Inputs to this clause C.3.1 Prerequisites Figure C.1 — Creating application specific software The prerequisites are in accordance with the relevant phasesin which software configuration is applied. C.3.2 Further supporting information See applicable further supporting information of the relevant phases in which software configuration is applied. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) C.4 Requirements and recommendations C.4.1 The configuration data shall be specified to ensure the correct usage of the configurable software during the safety lifecycle. This shall include: © Ay 9 Qa ) the valid values of the configuration data; ) the intent and usage of the configuration data; ) the range,scaling, units; and ) the interdependencies betweendifferent elements of the configuration data. C.4.2 Verification of the configuration data shall be performed to ensure: a) the use of values within their specified range; and b) the compatibility with the other configuration data. NOTE The testing of the configured software is performed within the test phases of the software lifecycle [see Clauses 9 (Software unit testing), 10 (Software integration andtesting), 11 (Verification of software safety requirements) and ISO 26262-4:2011, Clause 8 (Item integration and testing)]. C.4.3_ The ASIL of the configuration data shall equal the highest ASIL of the configurable software by which itis used. C.4.4 The verification of configurable software shall be planned, specified and executed in accordance with ISO 26262-8:2011, Clause 9. Configurable software shall be verified for the configuration data set that is to be usedfor the item development under consideration. NOTE Only that part of the embedded software whose behaviour depends on the configuration data is verified against the configuration data set. C.4.5 For configurable software a simplified software safety lifecycle in accordance with Figures C.2 or C.3 may be applied. NOTE A combination of the followingverification activities can achieve the completeverification of the configured software: a) “verification of the configurable software’, b) “verification of the configuration data”, and c) “verification of the configured software”. This is achieved by either — verifying a range of admissible configuration data in a) and showing complianceto this rangein b), or —__ by showing complianceto the range of admissible configuration data in b) and performingc). granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} Verification of configuration data Figure C.2 — Variants of the reference phase model for software development with configurable software anddifferent configuration data ISO 26262-6:2011(E) granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) Verification of configuration cata Software safety life cycle process Verification of configurable software integrationof configuration data Verification of configured software integration of calibration data Verification and validation software 1 Calibration Data m Verification of calibration data integration of calibration Gata Verification and validation software m Figure C.3 — Variants of the reference phase modelfor software development with configurable software anddifferent calibration data C.4.6 The calibration data associated with software components shall be specified to ensure the correct operation and expected performanceof the configured software. This shall include: a) b) the valid values of the calibration data; the intent and usageofthe calibration data: the range, scaling and units, if applicable, with their dependence onthe operating state; the knowninterdependencies betweendifferent calibration data: and NOTE Interdependencies can exist betweencalibration data within one calibration data set or between calibration data in different calibration data sets such as those applied to related functions implemented in the software of separate ECUs. the knowninterdependencies between configuration data and calibration data. NOTE Configuration data can have an impact on the configured software that uses the calibration data. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) C.4.7_ The verification of the calibration data shall be planned, specified and executed in accordance with ISO 26262-8:2011, Clause 9. Theverification of calibration data shall examine whetherthe calibration data is within its specified boundaries. NOTE Verification of calibration data can also be performed within application-specific software verification, or at runtime by the configurable software. C.4.8 The ASIL of the calibration data shall equal the highest ASIL of the software safety requirementsit canviolate. C.4.9 To detect unintended changes of safety-related calibration data, mechanisms for the detection of unintended changesofdata aslisted in Table C.1 shall be applied. Table C.1 — Mechanismsfor the detection of unintended changesof data Plausibility checks on calibration data Redundantstorageofcalibration data Methods 1c Error detecting codes? + ~ | es a 4 Error detecting codes may also be implementedin the hardware in accordance with ISO 26262-5. C.4.10 The planning of the generation and application of calibration data shall specify: a) the proceduresthat shall be followed; b) the tools for generating calibration data; and c) the proceduresfor verifying calibration data. NOTE Verification of calibration data can weauae checking the value ranges of calibration data or the interdependencies betweendifferent calibration data. C.5 Work products C.5.1 Configuration data specification resulting from requirements C.4.1 and C.4.3. C.5.2 Calibration data specification resulting from requirement C.4.6. C.5.3 Safety plan (refined) resulting from requirements C.4.1, C.4.4, C.4.5, C.4.9 and C.4.10. C.5.4 Configuration data resulting from requirement C.4.3. C.5.5 Calibration data resulting from requirement C.4.8. C.5.6 Software verification plan (refined) resulting from requirements C.4.2, C.4.4, C.4.7 and C.4.10. C.5.7 Verification specification resulting thai requirements C.4.4 and C.4.7. C.5.8 Verification report resulting from requirements C.4.1, C.4.4, C.4.7 and C.4.8. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) D.1 Objectives Annex D (informative) Freedom from interference between software elements The objective is to provide examples of faults that can cause interference between software elements (e.g. software elements of different software partitions). Additionally, this Annex provides examples of possible mechanismsthat can be considered for the prevention, or detection and mitigation ofthe listed faults. NOTE The capability and effectiveness of the mechanisms usedto prevent, or to detect and mitigate relevant faults is assessed during development. D.2 General D.2.1 Achievementof freedom from interference To develop or evaluate the achievementof freedom from interference between software elements, the effects of the exemplary faults, and the propagation of the possible resulting failures can be considered. D.2.2 Timing and execution With respect to timing constraints, the effects of faults such as those listed below can be considered for the software elements executed in each software partition: — blocking of execution; — deadlocks; — livelocks; — incorrect allocation of execution time; — incorrect synchronization between software elements. EXAMPLE Mechanisms such as cyclic execution scheduling, fixed priority based scheduling, time triggered scheduling, monitoring of processor execution time, program sequence monitoring and arrival rate monitoring can be considered. D.2.3 Memory With respect to memory, the effects of faults such as those listed below can be considered for software elements executed in each software partition: — corruption of content; — read or write access to memory allocated to another software element. EXAMPLE Mechanisms such as memory protection, parity bits, error-correcting code (ECC), cyclic redundancy check (CRC), redundantstorage, restricted access to memory, static analysis of memory accessing software andstatic allocation can be used. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} D.2.4 Exchangeofinformation ISO 26262-6:2011(E) With respect to the exchange of information, the causes for faults or effects of faults such as thoselisted below can be considered for each senderor each receiver: — repetition of information; — loss of information; — delay of information; — insertion of information; — masqueradeorincorrect addressing of information; — incorrect sequence ofinformation; — corruption of information; — asymmetric information sent from a senderto multiple receivers; — information from a sender received by only a’ subsetof the receivers; — blocking access to a communication channel. NOTE The exchange of information between elements executed in different software partitions or different ECUs includes signals, data, messages,etc. EXAMPLE1 Information can be exchangedusing |/O-devices, data busses,etc. EXAMPLE2 Mechanisms such as communication protocols, information repetition, loop back of information, acknowledgement of information, appropriate configuration of I/O pins, separated point-to-point unidirectional communication objects, unambiguous bidirectional communication objects, asynchronous data communication, synchronous data communication, event-triggered data buses, event-triggered data buses with time-triggered access, time-triggered data busses, mini-slotting, bus arbitration by priority and bus arbitration bypriority can be used. EXAMPLE3 Communication protocols can contain information such asidentifiers for communication objects, keep alive messages,alive counters, sequence numbers, error detection codes and error-correcting codes. granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) [1] [2] [3] [4] Bibliography ISO/IEC 12207, Systems and software engineering — Softwarelife cycle processes IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic safety-related systems MISRA-C:2004, Guidelines for the use of the C languagein critical systems, ISBN 978-0-9524156-2-6, MIRA, October 2004 MISRA AC AGC, Guidelines for the application of MISRA-C:2004 in the context of automatic code generation, ISBN 978-1-906400-02-6, MIRA, November 2007 granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} granularity=word contentanalysis={punctuationbreaks=false dehyphenate=false} layoutanalysis={tabledetect=0 layoutdetect=0} ISO 26262-6:2011(E) ee... ICS 43.040.10 Price based on 40 pages