The first part of ISO 26262 outlines terms and abbreviations used by the standard.
The second part defines management tasks required during different phases of a system’s safety life cycle.
It also outlines the organisational prerequisites that need to be fulfilled to develop a system in accordance with a required ASIL – an automotive safety integrity level relating to each level of a security requirement. ISO 26262 contains certain recommendations regarding different protective measures, depending on the level a system comes under.
The third part describes the concept phase, outlining the requirements, hazard analysis and risk assessments that have to be carried out.
The hazard analysis involves identifying potential threats to a system. To do this, malfunctions are examined. Each hazard is categorised according to ASIL level A to D, or classified as not safety-critical. The higher the ASIL level, the increasingly tight safety requirements become.
The fourth part deals with development processes on a system level in keeping with the V-Model. Methods and work products are outlined for each individual process.
Methods used to meet a requirement are classified according to each ASIL – as optional, recommended or strongly recommended. If a method that is not named can be shown to be effective, it may also be used.
The fifth part deals with development processes on a hardware level in keeping with the lower segment of the V-Model. It also outlines methods and work products for each individual process.
Methods used to meet a requirement are classified according to each ASIL – as optional, recommended or strongly recommended.
The sixth part deals exclusively with development processes on a software level in keeping with the lower segment of the V-Model. It also outlines methods and work products for each individual process.
The ASIL classification model applies in the same way as the other layers.
The seventh part deals with the process of production and installation planning. The aim is to meet the requirements of functional safety during the production and installation process.
The aim of the eighth part is to define and delegate responsibilities. The requirements of the safety life cycle are specified and configuration and change management are explained. This also involves defining how tools are used.
The ninth part deals with requirements decomposition with respect to ASIL and criticality analysis. Further part look at different analysis methods used to gain a better understanding of safety-critical failures and system breakdowns.
The tenth part provides examples of applications and supplementary details on ISO 26262.
This part is more for information purposes.
The eleventh part explains the impact ISO 26262 can have on the activities of semiconductor producers.
The last part deals with motorcycle development.
Scrum@Scale encourages companies to scale theirexisting scrum setting rather than establish a new framework. Instead of laying down rules, Scrum@Scale poses questions to allow stakeholders to develop scaling concepts themselves.
Synchronisation is achieved by using a product owner cycle and a scrum master cycle.
The structure of Nexus is even more minimalist than LeSS, based on low levels of formalised rules. These grant teams more leeway, synchronised by a Nexus integration team. By allowing for a higher degree of freedom, Nexus makes it possible for stakeholders to organise their own tasks more.
The scaled agile framework (SAFe) is the predominant model used by the automotive electronics industry to scale agile methods and practices on any level of the organisation. SAFe is particularly well suited to large development units responsible for delivering a high number of client projects in parallel.
Levels of the business covered by SAFe
- Teams
- Programmes
- Business solutions
- Portfolio management across the entire company
We use SAFe to synchronise these different levels by using a release train, also in order to allow your company to deliver continual benefit.
Large-scale scrum is particularly useful if your company needs to synchronise lots of scrum teams developing a system together. By synchronising scrum events, all stakeholders gain the same understanding. LeSS is based on a radically straightforward philosophy that is an excellent match for certain constellations within companies.
LeSS comprises a number of very simple fundamental elements
- Principles
- Rules
- Experiments
Security-centric processes are primarily useful when it comes to effective risk assessment.
They allow you to understand where potential threats will need to be thought about – in product development, production, and even during everyday use of the connected vehicle.
Measures designed to protect technology can be derived from the findings of risk assessments.
These allows you to protect connected vehicles from cyberattacks.
Protecting critical IT infrastructure according to ISO 27000 will prevent third-party access to connected vehicles via the back-end systems of the vehicle manufacturer, its suppliers and the service providers.
These include
- IT security
- Organisational security
