ISO TR 15497 pdf download – Road vehicles一Development guidelines for vehicle based software

ISO TR 15497 pdf download – Road vehicles一Development guidelines for vehicle based software.
3.2.4.2 Once the integrity level of the sofissare has been determined, an appropriate deeIopinent approach should be defined. Table 3 gives guidance for each integrity level.
3.2.4.3 The following notes should be read in conjunction with Table 3.
(a) Specification and design.
Automated code generation from a formal cification is recommended at level 4 in order to removc human error from the proccss. It is recognized that this is no possible with current technology, and that validated tools will be rcquircd to make the approach usable.
(b) Languages and compilers.
Most, if not all. languages do not have precisely dctined semantics, This means that not only may compilers contain faults, but different compilers for the same language may implement a given feature in ditTerent ways. In addition, some programming “features” such as pointers or recursion can cause unpredictable behaviour. This has led to the recommendation that restricted subsets are used at levels 2 and 3 and that certified compilers with proven formal semantics (not currently available) arc used at level 4.
Also, since there are currently no formally proven compilers. it may be necessary to show that the machine code lobject) does indeed reflect the high level language version (source) of the program. For this reason, or fir reasons such as required speed of execution or restricted memory availability, assembly languages arc still being used at all levels of integrity.
(c) Configuration management: producis.
‘Products” in this context means all documents generated or used during the development process (i.e. the set of information used for assessment). Additionally for level 2 and above, the tools used should also be under configuration management.
(d) Configuration management: process.
Conlirmation process at level 2 implies a means of confirming that the software has been built from identifiable components. At levels 3 and 4. the automated confirmation process is to confirm that only intended changes are made, and to perform automated impact analysis of proposed changes.
3.3.1 .4 Where appropriate, electrical isolation should be considered tór functions needing a high lesel of integrity. This will ease the de,nolLstratiofl of compliance with the safety requirements.
3.3.1 .5 To ensure all aspects are covered, split the work into functio,ial and implementation aspects, sometimes called logical and physical partitioning, and address each with a team Close cooperation and communication between these two architecture teams is essential.
3.3.1.6 For logical partitioning. create and maintain a model of the functional requirements of the complete vehicle electrical system. Split the functional requirements modelling into fuur phases:
• analysis of the high level requirements
• definition of the system boundary and the environment
• detailed lop-down mklling of the functional requirements
• implementation of functions on the vehicle hardware.
3.3.1.7 For physical partitioning:
• consider implementation (e.g. sensors and actuators) at an early stage to allow the architecture to encompass other vehicle design aspects such as packaging and body design
• identify the interfaces required by each subsystem lO identification)
• agree the available technology options that may affect the architecture (e.g. communications protocols and switching)
• review these optarns as the architecture study progresses.
3.3.1.8 Keep up to date lists of all current assumptions and open or unresolved issues made during the architectural design stage. Keep these under version control.
3.3.1.9 The vehicle manufacturer should pcrtbnn a proper ftrnctional analysis and maintain an overall system specification. If multiple suppliers are to be used for sourcing programmable components that are to be integrated, then this is essential to ensure that the component specifications given to each supplier are compatible.
3.3.1.10 Strict change control procedures should be enforced fur software, hardware and other appropriate design material at all times. Changes should be subject to review by the architecture teams responsible.