Path: EDN Asia >> Design Centre >> Automotive >> Impact of AUTOSAR, ISO26262 on car network design
Automotive Share print

Impact of AUTOSAR, ISO26262 on car network design

30 Oct 2014  | Andrew Patterson

Share this page with your friends

The ASIL classification for a complete system may be broken down into individual hardware and software elements, and in practice there will be a mixture of ASIL classifications in any given system. In theory, an ECU's entire software system must be developed to the highest ASIL level determined for any of the component elements – the chain is only as strong as its weakest link. This can overload the development effort significantly because even non-safety related software would need to be developed to the highest ASIL level. A technique called ASIL-decomposition offers a solution to this problem, such that individual software functions are developed in isolation to lower ASIL requirements, but additional functional redundancy is introduced so that an overall higher level of safety integrity is met.

Software development
Applying a safety mindset to the software development process means starting early in the cycle. Defining the failure modes and effects of the software should be approached in the same way as it would be for a hardware component. Each vehicle function and supporting software component definition needs to be traceable and linked back to a formal requirement specification, and have its own test plan, with defined expected results. Regression testing will typically be used to ensure that new features added do not break previously implemented and safety-approved functionality.

For safety-critical items, a failure-mode effects analysis will also be completed. In any production vehicle, software will come from many different sources including open source communities, third-party suppliers, as well as in-house developed software functions. Part of the validation plan will include the integration, test, and licence compliance of all assembled components. It is typically the Tier 1 supplier who will take responsibility for this, but the obligations cascade through the supply chain of software and hardware organisations.

How far can the developer trust the development tools such as software compilers and automated test tools being used on the project? How are these tools certified to meet the requirements of ISO26262? ISO26262 uses the concept of an overall "Tool Confidence Level" (TCL) to rate the confidence factor in specific tools used, with TCL1 being high confidence in the tool, with lower levels of confidence for TCL2 and TCL3. A TCL1 tool can be used in the development of safety systems "as-is" while lower confidence tools require additional testing or augmentation depending on the ASIL level of the system being created, which must be provided either by the tool developer or the organisation using the tool.

There are two main contributing components that determine the TCL – these are "Tool Impact" (TI) and "Tool Error Detection" (TD). The resulting Tool Confidence Level is determined from these two parameters.

The Tool Error Detection (TD) is graded from TD1 to TD3. TD1 means there is a high degree of confidence in the tool's ability to detect a defect in the software function; whereas TD3 is used in cases where not all behaviour scenarios are investigated by the development and test tools, so error and bug detection is not guaranteed. In the case that the software compiler introduces a problem, there needs to be a high probability that this can later be detected to ensure a TCL1 rating. Table 2 shows the relationship between these parameters.

Table 2: Deriving Tool Confidence Level (TCL) from impact and error detection capabilities.

Software tool providers can also provide a wide range of additional artefacts to demonstrate conformance of their tools and processes to ISO26262. These can include:

 • A description of features, functions, and technical properties (intended purpose, inputs and expected outputs, environment and functional constraints)
 • A product user manual
 • Environment required for safe operation of the software tool
 • Description of expected behaviour of tool under anomalous operating conditions (if applicable)
 • Description of known bugs, safeguards, workarounds
 • Information on how an incorrect tool output would be detected
 • How to review and analyse tool output
 • How to perform tests on the tool itself

 First Page Previous Page 1 • 2 • 3 Next Page Last Page

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact