Product development standards: Case study of ISO 26262 automotive safety
Let’s break the myth surrounding the tough standards that product developers have to adopt. Standards and norms in the industry are great when it comes to ensuring product quality, reliability and safety. From optimizing methodology and techniques during the development cycle, it also ensures the systematic tracking and debugging throughout the process very manageable. These are great when it comes to developing your product, ensuring its life-cycle reproducibility and reusability to a family of products, accountability and overall great for satisfying customer expectations. Product sales are won and lost over the standards adopted. In my industry (Automotive) this is true with a strong scented.
The idea of this article is to paint the light showing why adopting standard industry norms into your product development processes is an idea that makes a huge difference on the business. And a user why you need to look out for these standards in approach during development why it brings a lot of end value. The second and major part is to introduce ISO 26262 norms, as safety standard adopted in the automotive industry, and understand what the recent buzz is all about in the shifting plates.
Standard norms — An Overview
Every product market has its set norm standards based on the industry for products to comply with, based on their classification. Chemical safety, Medicinal product safety, Food safety, Requirement checks for goods are standard processes in the product life-cycle to comply with as examples. Let’s get a bit narrow with software products for the sake of any meaningful discussion. The landscape of electronic products, which mark a huge spectrum of products, have evolved and transformed quite rapidly to capsule a lot of software. Equipment manufacturers while complying with the instrument standards need also to pay caution at the software level. The amount of data flow and processing in the system have increased significantly, which upon further insight is also great news for product developers to develop new utilities that solve problems. So what is with software in the automotive industry?
Case study of the ISO 26262 — Functional safety in the automotive industry
With the evolution of the functionalities in car, the number of ECUs have increased tremendously in the last decade and are constantly increasing. The car is no longer seen just as a mobility machine. With development of ADAS features the safety standards of products have become more and more critical. A more rigorous software development needs to be put in place. One of the many standards that ensures this is the ISO26262 standards. This significant to safety and quality of the product. It ensures that failures in the system do not lead to condition that could cause the system to be dangerous. Part 6 of the ISO 26262 standards is meant solely for the software. Clearly intrinsic quality is more likely to perform safely and demonstrably safe.
What is the standard?
The ISO 26262 standard is an international standard focusing on the automotive electrical and electronic safety. Put together by suppliers and OEMS it specifies standards to be followed to keep the development completely reliable irrespective of tools and methodologies used.
It takes a risk based approach on the severity, exposure and control-ability and defines the level of importance and associated risks into four Automotive Safety Integrity levels or ASILs. (A low to D high). When OEMs or Auto manufacturers, consolidate their specifications they also specify the require Automotive safety integrity level (ASIL level — A to D) of the component and ultimately influence the design of the platform form a functional safety perspective.
The Biggest advantages
The customer and the general market benefit a lot from the standards
1. The benefits seem non trivial given the higher development times and costs (the rough estimate is per ASIL level upgrade multiplies the development cost by a factor of 10) on a single product case but over all over the entire cycle it creates a flow upstream and downstream from requirements to implementation and saves time
2. It ensures quality of the product to the customer
3. It allows clear understanding of the process to optimize
4. It ensures the written codes are readable, common standards are followed for transfer of work, traceable to the implementation level, track-able to associate the responsible for each and every part of the development
5. It gives the developer, requirement architects, testers an overview into each-others tasks so their efforts could be implemented in a much synthetic manner. For the end user it is a more reliable product. And this scores high, when it comes to later stages of product marketing and sales.
How to improve your tool chain to fit the process?
Above is a classic V model adopted in most of the software development products. In each of the segment mapping the development segment with the ISO 26262 requirements is the end goal. It is important to mention safety is just one aspect of the development, so redefining these processes with finer sub phases is the way forward. For example, code inspection done during even the design phase and having an understanding of the ISO 26262 requirements during the requirement and architecture phases would enable a much more efficient testing phases. The best practices and lesson learnt and good documentation create a stronger evolution and minimize efforts. ISO 26262 doesn’t specify the specific methodologies and there are plenty of tools available in the market that give competitive results, it is up to the organization put together a matrix of their resources and tool chains. Model based development is getting heated attention is helps implementing the ISO 26262 processes faster.
Key takeaways
1. Adopting the industry standards ensures product longevity
2. The cost of development for higher critical standards increasing and are higher however implementing processes reduce overheads on the longer cycle of development especially during product diversification
3. Software growth in product business and especially in Automotive industry has been on a constant increase, product owners need to have a shared plan of their software timeline
4. ISO 26262 standards are must in automotive development including software
5. ISO 26262 defines the ASIL levels of requirements and suggest methodologies for tool chains to be put in place on the requirements, implementation, testing, and bug fixing.
6. Trace-ability, readability, robustness, optimization, re-usability are some key outcomes of the ISO 26262 process
7. To familiarize yourself with this process read the link below where you have the complete available guideline and contact experienced engineers to support you improve your product cycle
References
I would like to thank the Feabhas team and the sesame project team for their existing content that helped create this basic understanding for any one new to the standards. Recommend referring to their detailed material below. Do contact me for more information.
Cover photo by Bernard Hermant on Unsplash
