WIXLIB

W H I T E PA P E RGuide to ISO 26262Software ComplianceAchieving Functional Safety in the Automotive Industry

Technical WhitepaperGuide to ISO 26262 Software ComplianceINTRODUCTIONSome modern automobiles have more lines of code than a jet fighter. Even moderately sophisticatedcars ship with larger and more complex codebases than the same line from just a few years ago.The inclusion of multi-featured infotainment systems, driver-assist technologies, and electronicallycontrolled safety features as standard components—even in economy models—have fueled thegrowth of software in the automotive industry. Additionally, the emergence of driverless technologyand “connected” cars that function as IoT systems on wheels will mean even larger and morecomplex codebases.All of the innovation taking place in the automotive industry, though, raises concerns over the safety,security, and reliability of automotive electronic systems. The concerns are appropriate given thatthe automotive software supply chain is a long convoluted system of third-party providers spanningseveral tiers. Consider, for example, that software developed for a specific microcontroller unit (MCU)may be integrated by a third-tier provider into a component they’re shipping to a second-tier providerand so on—until a composite component is delivered for final integration by the automaker.While not all automotive software is critical to the safe operation of the vehicle, code that carries outfunctional safety operations must be safe, secure, and reliable. Organizations must implement strongsoftware quality process controls around the development of safetycritical software in accordancewith ISO 26262, which is a functional safety standard for automotive software. ISO 26262 providesguidance on processes associated with software development for electrical and/or electronic (E/E)systems in automobiles. The standard is aimed at reducing risks associated with software for safetyfunctions to a tolerable level by providing feasible requirements and processes.In this paper, we provide background information on ISO 26262 and its goals. We also discuss someof the policy-related issues associated with developing embedded software that complies with ISO26262. Finally, we describe how Parasoft can help automotive software development organizationsachieve compliance with ISO 26262.2

Technical WhitepaperGuide to ISO 26262 Software ComplianceWHAT ISO 26262 COVERSISO 26262 is a functional safety standard thatcovers the entire automotive product developmentprocess (including such activities as requirementsspecification, design, implementation, integration,verification, validation, and configuration). Thestandard provides guidance on automotive safetylifecycle activities by specifying the followingrequirements:» Functional safety management for automotiveapplications» The concept phase for automotive applications» Product development at the system level forautomotive applications software architecturaldesign» Product development at the hardware level forautomotive applications software unit testing» Product development at the software level forautomotive applications» Production, operation, service anddecommissioning» Supporting processes: interfaces withindistributed developments, safety managementrequirements, change and configurationmanagement, verification, documentation, useof software tools, qualification of softwarecomponents, qualification of hardwarecomponents, and proven-in-use argument» Automotive Safety Integrity Level (ASIL)oriented and safety-oriented analysesWHAT ISO 26262 DOES NOTCOVER» Unique E/E systems in special purposevehicles such as vehicles designed for driverswith disabilities» Safety standards for large vehicles, suchas those over 3500KB (7700 pounds) grossweight» Hazards related to electric shock, fire,smoke, heat, radiation, toxicity, flammability,reactivity, corrosion, release of energy andsimilar hazards, unless directly caused bymalfunctioning behavior of E/E safety-relatedsystems» Nominal performance of E/E systemsSOFTWARE-SPECIFICSECTIONS OF ISO 26262Part 6 of the standard specifically addressesproduct development at the software level.Requirements for the following developmentactivities are specified:» Initialization of product development» Specification of software safety requirements» Software architectural design» Unit design and implementation» Unit testing» Software integration and testing» Verification of software safety requirements.Methods defined by the ISO 26262 standardshould be selected depending on the ASIL(automotive safety integrity level). The higher theASIL, the more rigorous the methods.3

Technical WhitepaperGuide to ISO 26262 Software CompliancePart 8, section 11, describes the softwaretool qualification process. Tools that automatesoftware development activities and tasks cansignificantly help organizations meet ISO 26262requirements. Software tool qualification isintended to provide evidence that tools aresuitable for developing a safety-related itemor element. One of the qualification methodsdefined in ISO 26262 relies on running thedevelopment tool on a control codebase andmaking sure that the product is consistentand accurate.Qualifying Parasoft defect prevention tools andtechnologies involves running static analysis,flow analysis, unit tests, and any other testingpractice used in your development process ona set of control code. Parasoft will consistently,accurately and objectively report errors, whichensures that the tool functions properly.Item definitions that includeassumptions, dependencies,and a preliminary architectureare written.ItemDefinitionISO 26262 COMPLIANCEAND POLICY-DRIVENDEVELOPMENTA particular feature that makes developingcompliant embedded software so challengingis the gap between software development andbusiness expectations. Software engineers makebusiness-critical decisions every day in the formof their coding practices, quality activities, andengineering processes. As software permeatescritical functions associated with functionalsafety, these engineering decisions can leadto significant business risks. E/E systems inautomobiles that must conform to ISO 26262are particularly vulnerable to risks becausethe standard specifies very detailed lifecycleprocesses throughout the approximately400 pages intended to answer a simple, yetambiguous, question: Is this safe?Item definitions are the basisof hazard analyses, whichresult in a list of terminedEach event is given an ASIL(automotive safety integritylevel) and assigned a safetygoal.Safety GoalsAssigned toEach EventAnalysisSafety GoalsInherit EventASILsFSRs are converted to TSRs.Figure 1:Software developmentlifecycle defined rementsISO 26262Each TSR isImplementedby a SoftwareSafetyRequirementAll steps output work products.Work products comprise a safety case.Additional arguments accompany thesafety case to answer the question of safety.4

Technical WhitepaperGuide to ISO 26262 Software ComplianceThe purpose of ISO 26262 is to outline thepolicy surrounding the processes in Figure 1,but policies specific to the organization can beintegrated at any step.The key to reining in these risks is to alignsoftware development activities with yourorganization’s business goals. This can beachieved through policy-driven development,which ensures that engineers deliver softwareaccording to your expectations. Policy-drivendevelopment involves:» Clearly defining expectations anddocumenting them in understandable polices.» Training the engineers on the businessobjectives driving those policies.» Enforcing the policies in an automated,unobtrusive way.By adopting a policy-driven strategy, businessesare able to accurate and objectively measureproductivity and application quality, whichlowers development costs and reduces risk.With public safety, potential litigation, marketposition and other consequences on the line,it behooves software development teams andpeople in the traditional business managementpositions to come together on policy andimplement the strategy into their softwaredevelopment lifecycle.TRY PARASOFT DTPLearn more about policy-driven development.PARASOFT SUPPORT FORISO 26262Parasoft DTP facilitates the software qualitytasks specified in ISO 26262, including staticanalysis, data flow static analysis, metricsanalysis, peer code review, unit testing andruntime error detection. This provides teams apractical way to prevent, expose, and correcterrors in automotive functional safety systems.DTP collects data generated by softwareengineering processes, such as static codeanalysis violations, test results, code metrics,coverage analysis, source control check-ins,defect tracking systems, etc., and generatesmeaningful views of the correlated andprioritized data.The real power of DTP is the Parasoft ProcessIntelligence Engine (PIE), which performs anadditional post analysis on the developmentartifacts collected in order to pinpoint risk inthe code while highlighting opportunities forimproving the your development processes. DTPreports the problematic code and a descriptionof how to fix it to the engineer’s IDE based onthe organization’s programming policy.The specific sections of the ISO 26262, part 6:Product development: software level that can beaddressed or partially addressed with Parasoftare described below. The information presentedhere is intended to serve as an introduction toISO 26262 software verification and validationprocesses with Parasoft. Please refer to thestandard and consult functional safety expertsfor clarification of any requirements defined bythe ISO 26262 standard.5

Technical WhitepaperGuide to ISO 26262 Software ComplianceINITIALIZATION OF PRODUCT DEVELOPMENT AT THESOFTWARE LEVELThis section of the ISO 26262 Part 6 standard defines general information about the process ofsoftware development and validation.5.4.6 Requirements for achieving correctness of software design and implementation.Methods described here apply to both modeling and programming languages.REQUIREMENTEnforcement of low complexityUse of language subsetsEnforcement of strong typingPARASOFT CAPABILITY» Reports cyclomatic complexity, essentialcomplexity, Halsted complexity, and othercode metrics» Coding standards enforcement,e.g., detection of unsafe languageconstructions» Implicit conversions detection» Enforces defensive programming againstUse of defensive implementation techniquesUse of established design principlesUse of unambiguous graphical representationUse of style guidesUse of naming conventionsappropriate coding standards rules, e.g.,checking the return value of malloc,checking the error code value returned bycalled functions, etc.» Enforcement of industry coding standardsrule sets, e.g. MISRA C/C , JSF, HISsource code metrics, etc.» Enforcement of specific formattingconventions» Enforcement of specific codingconventions» Enforcement of specific namingconventions6