• Video
  • 17-May-2012 03:46 EDT

Automotive Functional Safety Standard ISO 26262 and the Current Challenges

00:14:54
Length:

Purchase Required to View Video

Short Preview Below

The ISO 26262, titled "Road vehicles - Functional safety," is a Functional Safety standard that gives a guidance to reduce the risks to tolerable level by providing feasible requirements and processes. This standard is an adaptation of the Functional Safety standard IEC 61508 for Automotive Electrical/Electronic and programmable electronic Systems. The standard covers the development of safety-related electrical, electronic and programmable electronics systems in the road vehicles. It will have a significant impact on the way such systems are designed, developed, integrated and validated for safety. Functional safety of embedded systems has become an integral part in automotive engineering activities due to the recently released safety standard ISO 26262. One main challenge is to perform development activities compliant to the standard and provide the respective documentation. Traceability between requirements from a standard, as well as project-specific process and product artifacts throughout the entire development cycle allows compliance assessment to support qualification and certification. The author would like to share the challenges faced through her experience gained in the field with examples from various automotive tier-1 suppliers. The challenges I would like to address are the following: -The resource planning and the cost for the entire functional safety activity -The documentation requirements Maintenance of the same with right traceability -One of the major challenges is the derivation of safety goals with right ASIL level. Hazard Risk analysis (HARA) forms the basis of the entire functional safety activity. The HARA determines the safety goals for the system and the same becomes the basis for deriving functional safety requirements followed by Technical safety requirements which gets translated into HW/SW Design -The ASIL assignment is dependent on the three factors severity, exposure and controllability. Unless we have adequate data and experience the ambiguity exists on the assignment. -Functional safety activity distribution between the OEMs and Suppliers. OEMs have several suppliers and the supplier in turn outsources certain items to sub suppliers. In this process percolating the functional safety requirement derived at the highest level to the supplier items level is to be systemized. I do see the challenges in ownership. -The depth of details to go in the Functional safety requirement and Technical safety requirement documents -Under ASIL decomposition assigning ASILs on decomposition to the respective architectural elements. -It is mandatory to comply the quantitative assessment for HW and obtaining failure rate for all the components used in a system becomes a challenge. Especially we are completely dependent on the failure rate given by the vendor on ASICs and other custom made components. -Proof of avoidance of common failure and cascading failures in the Software level and thus prove the freedom from interference between lower and higher ASIL elements. -Assigning the Diagnostic coverage for the safety mechanisms provided taking the guidance from Appendix D part 5. We always get to a situation where we are not able to map within the list provided. Then one needs to have their own scale which would result in ambiguity.

Presenter
Chitra Thyagarajan

Buy
Select
Price
List
Purchase to View
$19.00
Share
HTML for Linking to Page
Page URL
Grade
Rate It
1.0 Avg. Rating
1 votes

View More Video

Video
2012-01-24
Some the OBD-II regulations have been around for a long time or seem to be intuitively obvious. It is easy to assume to assume that everyone knows how to implement them correctly, that is, until someone actually reads the words and tries to do it. Most often, these issues come up when modifying existing OBD features, not when creating completely new ones. This presentation contains a few examples of features that should have been easy to implement, but turned out not to be easy or simple. Presenter Paul Algis Baltusis, Ford Motor Co.
Video
2012-03-21
In recent years, all major microprocessor manufacturers are transitioning towards the deploymenet of multiple processing cores on every chip. These multi-core architectures represent the industry consensus regarding the most effective utilization of available silicon resources to satisfy growing demands for processing and memory capacities. Porting off-the-shelf software capabilities to multi-core architectures often requires significant changes to data structures and algorithms. When developing new software capabilities specifically for deployment on SMP architectures, software engineers are required to address specific multi-core programming issues, and in the ideal, must do so in ways that are generic to many different multi-core target platforms. This talk provides an overview of the special considerations that must be addressed by software engineers targeting multi-core platforms and describes how the Java language facilitates solutions to these special challenges.
Video
2012-02-01
The presenter will discuss challenges introduced by OBD in developing a product for worldwide markets and the impact of varying worldwide requirements for OBD performance and certification. Presenter Benjamin Zwissler, Cummins Inc.
Video
2011-12-05
These advanced checks have resulted in development of many new diagnostic monitors, of varying types, and a whole new internal software infrastructure to handle tracking, reporting, and self-verification of OBD related items. Due to this amplified complexity and the consequences surrounding a shortfall in meeting regulatory requirements, efficient and thorough validation of the OBD system in the powertrain control software is critical. Hardware-in-the-Loop (HIL) simulation provides the environment in which the needed efficiency and thoroughness for validating the OBD system can be achieved. A HIL simulation environment consisting of engine, aftertreatment, and basic vehicle models can be employed, providing the ability for software developers, calibration engineers, OBD experts, and test engineers to examine and validate both facets of OBD software: diagnostic monitors and diagnostic infrastructure (i.e., fault memory management).

Related Items

Technical Paper / Journal Article
1918-01-01
Technical Paper / Journal Article
1917-01-01
Standard
2011-06-01
Technical Paper / Journal Article
1920-01-01
Training / Education
2010-03-15
Technical Paper / Journal Article
1996-04-01
Article
2016-07-01
Training / Education
2007-03-01
Technical Paper / Journal Article
1917-01-01