A quick guide to ISO 26262[1]_0_0.pdf对2018版ISO 262

文件名称: A quick guide to ISO 26262[1]_0_0.pdf

所属分类: 电子政务

开发工具:

文件大小: 3mb

下载次数: 0

上传时间: 2019-07-15

提供者: zxiao******

下载 (3mb)

不能下载？报告错误

详细说明：对2018版ISO 26262的快速指导,对ISO2626做一个简单描述,可以快速对ISO26262有个了解.Is ISo 26262 just about software development? ISo 26262 covers the entire product development lifecycle of electrical /electronic automotive products. The standard is composed of 10 parts, as shown below: Part 1: Vocabulary Part 2: Management of Functional Safety Part 4: Systems Level Development Part 5: Part 3: Concept Production and Part 5 Part 6 operation Hardware Software Part 8: Supporting processes Part 9: ASIL-oriented and safety-oriented analyses Part 10: Guidelines Figure 1- The parts of ISO 26262 Part 1 defines the language of iso 26262-terms abbreviations acronyms, etc Part 2 is an over-arching guide focusing on the management of safety requirements both from a project and organisational point of view Part 3 focuses on what ISo 26262 calls the concept phase. This phase is concerned with initial project definition, establishing the safety requirements and criteria for the project and initiating the safety lifecycle Part 4 is concerned with systems level development-that is, detailed requirements analysis, system synthesis, functional and logical allocation, and system evaluation, validation and verification Part 5 covers the hardware aspects of system design and implementation Part 6 focuses on the software aspects of system design and implementation Part 7 details requirements for system production, operation, installation, servicing, decommission, etc Part 8 defines requirements for processes that support the development effort, including change management documentation standards tool qualification verification and validation etc Part 9 gives requirements and guidance with respect to safety analyses; in particular all aspects related to ASIL-oriented requirements Part 10 gives guidance on applying ISo 26262. This document is current/y under development FEABHAS So iso 26262 is a process? No. Although many people believe it does describe a process ISo 26262 makes the assumption you are already working to a defined development process. The standard applies additional constraints to your process focussed on the system safety aspects ISo 26262 uses a classic 'V-model' framework to organise its requirements. the v-model is a standard way of describing the relationship between your development artefacts Require System ments test Architec Integrati ture on test Design Unit test Code Figure 2-a classic V-mod Every development process should contain-in some form- the elements shown on a v-model; but perhaps not exactly as required by iso 26262. Complying with iso 26262 will normally mean mapping existing design artefacts onto iso 26262 Work Products Figure 3-Iso 26262 adds additional constraints on top of your development process FEABHAS The confusion arises because many engineers mistakenly believe the v-model describes a process with workflows and activities. In fact there are many ways to traverse the v-model -waterfall processes, Agile processes, etc What additional constraints does iso 26262 impose? ISo 26262 is focussed on the safety aspects of the system under development. the additional rigour (effort) that iso 26262 imposes is focussed on ensuring the system meets its safety requirements For any particular process step iso 26262(in general) requires the following aspects be considered Tool Aspects Techniques ocess Safety Aspects Methodologies Artefacts Figure 4- Additional process aspects required by iso 26262 Tool Aspects The developer must consider what tools will be used at each stage the applicability of the tools; and how they will be used Techniques For each process stage what ISo 26262 calls a ' sub-phase )iso 26262 specifies a set of recommended techniques(for example, code inspection). Higher levels of integrity have more recommended techniques; and techniques move from being suggested to ' required Methodologies Although ISo 26262 specifies a comprehensive set of techniques it does not give any guidance on how to apply them that is, iso 26262 does not specify any methodologies -for example, use of oo design The development organisation must, however, specify and document methodologies /best practices/guidelines for each sub-phase of the development FEABHAS Artefacts Artefacts capture the output of the design process. ISo 26262 calls these Work Products and is somewhat prescriptive in the work products that must be produced at each stage Safety Aspects Safety aspects are those inputs or methodologies directly related to system safety; as opposed to system intrinsic quality What's the impact of AsILs? ASILs are used to configure the iso 26262 requirements. In general, the higher the asil the more rigorous the development must be To be compliant with ISo 26262 the development organisation must perform all the activities and produce all the work products specified by the standard. the difference is the amount of work (the rigour that must be done at each stage ASILs are used to select appropriate techniques at each sub-phase. Techniques are specified and can be interpreted as followed "Highly Recommended"(++) These techniques are, for all practical purposes, mandatory highly recommended techniques must be applied. If the technique is not to be applied, there must be a very compelling justification for why it is being omitted ecommended"(+) Recommended techniques are good practice although not strictly demanded by the standard. You should be doing recommended practices as part of your normal development anyway. If the development organisation is not going to perform a Recommended practice it should justify the reasons No Recommendation"(o The standard has no opinion on the technique. this could be interpreted as optional (if you are not already performing the technique) What's the financial impact of higher aSIL? Although there is no fixed calculation it is generally accepted that each increase is asil level causes a ten-fold increase in cost, due to the extra levels of rigour and effort required That is, an ASIL B system will be ten times more expensive that an ASIL A; an ASIL C one hundred times; and an asil d one thousand times more expensive FEABHAS It remains to be seen whether the automotive embedded systems industry can withstand such an increase in development costs; or what the consequence for safety-critical systems in automotive applications will be How does part 6 Software fit in with the rest of ISo 26262? IS0 26262 makes a clear distinction between Systems Engineering, and Software and Hardware development Systems Engineering is focussed on requirements capture, system design and evaluation and allocation of system behaviour (and appropriate qualities of service onto hardware software(and mechanical components). the outputs from the systems process are software and hardware design specifications R Vicat Ical s Han e 只 Figure 5- the relationship between Systems, Software and Hardware in ISo 26262 The software design process(Part 6) focuses on the development of software on one(or possibly more, depending on the systems design) microcontroller There is a potential overlap(and weakness in the process)between software allocation design and systems engineering. This overlap will need clarifying by the development organisation FEABHAS What's the difference between iso 2 6262 and IEc 61508? ISo 26262 is a variant of lEC 61508, designed specifically for the automotive industry IEC 61508 was originally intended for use with large industrial safety-critical systems - chemical plants, nuclear reactors, etc. With such systems, installation is a major part of the safety process Commonly automotive embedded systems are sold as oEm products; and the installation process is not critical in the safety of the device. ISo 26262 drops most of the installation standards from ieC 61508 ISo 26262, being a newer standard acknowledges many of the common practices used in automotive embedded systems development-particularly model-based development, using tools like matlab or labview Finally,IEC 61508 gives guidelines regarding documentation requirements. IS0 26262 is rather more prescriptive about the documents you are required to produce Example Systems Below are typical examples from each of the asil levels: an aSIl level a system, aSIL level b, etc These systems should be taken as representative only-that is, not all cruise control systems will be levela In these examples the IS0 26262 techniques for each development phase will be listed. It is assumed that where a technique is listed as highly recommended you must apply it; recommended techniques should be performed; and techniques with no recommendation are considered optional and can be omitted. The aim is to suggest the minimal set of required techniques for each ASIL level Remember also that the standard does not contain any methodologies for achieving the required rigour levels. Where a technique is specified the standard does not give any guidance for how, when or where the technique must be applied FEABHAS ASIL Level D System- Electric Steering wrong level of assistance or feedback, or even completely incorrect output locking the steering The electric steering system has the potential to cause significant harm -for example, providing tl against an end-stop Initiation of software development The focus of this sub-phase is the planning of the software development activity with particular emphasis on ensuring appropriate tools, methodologies, guidelines, etc are in place With regard to modelling guidelines the following techniques should be covered Table 1 -Coding and modelling guidelines Technique Highly Recommended Recommended Enforcement of low complexity Use of language subsets Enforcement of strong typing Use of defensive implementation techniques Use of established design principles Use of unambiguous graphical representation Use of style guides Use of naming conventions Specification of software safety requirements The emphasis of this sub-phase is ensuring the approach taken to ensure software safety is consistent with the system safety philosophy IS0 26262 provides recommendations for this sub-phase but does not specify any recommended techniques Software architectural design In this sub-phase the software architecture is synthesised evaluated and verified lso 26262 defines architectural design' as the design of the software down to the level of an implementable component. There is no guidance given on what this constitutes but it can be assumed to be an Individual module, package or class Iso 26262 defines techniques for design notations for the software architecture. FEABHAS Table 2 - Notations for Architectural design Technique Highly Recommended Recommended Informational notations Semi-formal notations Formal notations The standard also encourages high intrinsic quality at the architectural level in order to avoid (for example) failures due to over-complicated designs. the following principles are specified Once again, the standard gives no guidance on how these principles should be achieved or how they should be evaluated Table 3- Principles for architectural design Technique Highly Recommended Recommended Hierarchical structure of software components Restricted size of software components Restricted size of interfaces High cohesion within each software component Restricted coupling between software components Appropriate scheduling properties Restricted use of interrupt One of the key safety mechanisms for software is error detection and handling. ISo 26262 specifies the use of the following techniques for error detection Table 4-Mechanisms for error detection at architectural level Technique Highly Recommended Recommended Range checks of input and output data Plausibility checks Detection of data errors(e. g parity checking External monitoring facility Control flow monitoring Diverse software design Correspondingly, the standard defines acceptable error handling strategies FEABHAS

(系统自动生成,下载前可以参看下载内容)