John Lindland presents the second in a series of articles that set out to describe the intent of functional safety, and how to design for functional safety, drawing on content from a soon-to-be published book, Design for Functional Safety, The Concept Design Phase.
The first article in this series, The basis of ISO 26262 Road Vehicle Functional Safety – designing for functional safety, can be found here: FEATURE: The basis of ISO 26262 Road Vehicle Functional Safety – designing for functional safety | Autonomous Vehicle International
An Overview of Road Vehicles Functional Safety ISO 26262
“This topic lightly covers all 12 of the parts of ISO 26262 Road Vehicle Functional Safety. It provides a solid overview of the ISO 26262 work product parts. These are Part 3 The concept design phase, Part 4 the system design phase, Part 5 the hardware design phase, and Part 6 the software design phase. The article interweaves design for functional safety and introduces the concept of statistical capability of the design as well as the five levels of mastery of function.”
ISO 26262 includes 12 parts to the complete standard. Part 1 is the vocabulary. Part 2 is the management of functional safety and includes the requirement that the company becomes registered to IATF 16949 Automotive Quality Management System. Parts 3-7 cover the functional safety work product and safety case requirements and will be covered in the following article. Part 8 covers the required supporting processes that need to be documented and included in the IATF 16949 quality management system. Part 9 guides the Part 3 Hazard Analysis and Risk assessment and explains the ASIL analysis. Part 10 covers functional safety guidelines and relationships between the ISO 26262 parts. Part 11 explains the relationship between semiconductors, their hazard rates, and supports Part 5, The Hardware Design Phase. Part 12 covers the adaptation of ISO 26262 to motorcycles.
The concept phase creates clear guidance for the system design phase, and this includes the planning for staffing and creating business processes. The system design phase fine-tunes the concept design and produces clear hardware and software functional safety requirements. It also validates the relationships of hardware-software, hardware/software as a system, and the system to vehicle relationships, including the statistical capability of the autonomous vehicle level functions controlled by the design.
Part 3
The Concept Design Phase has three work products which are: the Item Definition, Hazard Analysis and Risk Assessment (HARA) with Vehicle Level Safety Goals, and the Functional Safety Concept with its Functional Safety Requirements.
The Item Definition is where the future system is described. Its basic requirements for OEDR while active are detailed; what it senses and understands, and how autonomous vehicle level functions respond provides the conceptual basis for performing the HARA. The HARA considers the driving environment of the Operational Domain Definition which includes roads/streets, pedestrians, pedal cyclists, vehicles, order/chaos, weather, day/night, and so on. Streets, roads, highways, limited access highways have differing geometries and interrelations. They offer differing risks of interacting with pedestrians, pedal cyclists and other vehicles. All driving surfaces of each type of roadway are made up of representative road segments. Solving OEDR on the most complex of each representative road segment means that all other road segments of that type have been solved. Splitting the ODD into different representative road segments provides the basis for performing the HARA.
Each representative road segment offers up to 36 different precrash scenarios (NHTSA). How vehicle level functions can misbehave in any representative road segment can be considered along with its specific precrash scenario and hazard (pedestrian, pedestrian, vehicle). Improper vehicle level functions are linked/traceable to each hazard. If a human is present during a precrash scenario, a potential hazard exists. Human presence is estimated by Exposure. The risk of injury that relates to exposure is Severity. A driver/passenger’s ability to override autonomy and avoid injury is estimated by Controllability. Human presence includes a pedestrian, pedal cyclist or vehicle. What the Item is required to see, understand and how it is supposed to respond provide the basis for the Functional Safety Concept, which is a rough draft system design. Each precrash scenario describes the preferred or safe vehicle level function. The safety goal of each precrash scenario is to produce the desired vehicle level function that avoids the specific misbehaving vehicle level function in each specific scenario.
The Functional Safety Concept addresses all risks from the HARA with the intent of achieving the Safety Goals. Each precrash scenario will identify the desired vehicle level response (steering, acceleration, deceleration or braking) that would avoid entering into a precrash scenario or to safely maneuver through a complex driving scenario. This defines the Object and Event Recognition and Response requirements. Initial sensor requirements are determined. How to define the potential events are determined (object tracking, object prediction, motion constraints, motion control, motion planning-the safe driving path, safe dynamic controls, vehicle level controls, map references, relative and ground truth localization, etc.). Potential failure modes are identified. Potential fault detections, alternate safe responses and emergency operating times are created. Initial safety mechanisms are identified with their Fault Tolerance Time Intervals. The structure of the design, redundant hardware/software through ASIL Decomposition, is considered.
The Functional Safety Concept is a detailed rough draft design upon which the System Design Phase will be built. Staffing requirements planning for system, hardware and software can be estimated including job descriptions, goals and head counts for design, quality, functional safety, validation testing, lab support, supervision, and management. It provides clear goals for the system design. This includes the design, development and testing procedures that are needed. It provides the ability for effective project management that can manage deliverables based on defined and documented design control procedures and records, including safety case evidence, and so on. A safety case should be the natural result of creating and validating a safe design. The system requirements that will need to be refined and validated are identified. Business planning and staffing needs to include becoming registered to IATF 16949 Automotive Quality Management System or a different country’s Automotive Quality Management System (ISO 26262 Part 2 requirement). IATF must include all the ISO 26262 required supporting processes. IATF must also include all ISO 17025 required processes for producing valid safety cases. Safety cases need to be a natural byproduct of creating a safe autonomous design.
As a rough timeline, it takes six months to one year to create the required documented procedures, work instructions and records. Each manager/executive is responsible for the effective management of their business processes. Roughly 15-20% of QMS processes belong to the quality department. It takes one year of use and improvement to prove that the business is stable and self-correcting. This is about the length of time that it would take to satisfy the Concept Design Phase and complete the work required for The System Design Phase’s Technical Safety Concept. This means that all work performed could be produced in the required stable work environment.
Part 4
System Design Phase has two parts. These are: 1) the Technical Safety Concept and 2) Integration and Testing.
The first part of the system design phase is the Technical Safety Concept. The system design phase finalizes the decomposition of hardware and software functions. For highly automated vehicle designs (Levels 3-Level 5), the goal is to design a minimum of two fully independent functional paths from sensors to vehicle level functions. Independent means that they will not share a common causes of system failures. One of two paths is always available to assume safe control of the vehicle. Level 3-Level 5 will always assign ASIL D to steering, acceleration, deceleration and braking. Two paths would decompose ASIL (D) into ASIL B(D)+ASIL B(D). It might also include a third path with automotive grade E/E hardware from sensors to vehicle level functions. This would be ASIL (D)=ASIL B(D)+ASIL B(D)+QMS.
The QMS are E/E computational devices of automotive grade and are produced under the controls, verification, validation and production of the automotive IATF 16949 quality management system (Re: ISO 26262 Road Vehicle Functional Safety Part 2). All three paths would be monitored for hardware, software, hardware software interface (HSI), and E/E board diagnostics faults. The QMS technical solution is only used for an emergency safe stop off the driving surface. Without this QMS path, when one of the two ASIL B(D) paths fails, the autonomy must safely stop the vehicle off the driving surface. The safe stop is controlled by the remaining ASIL B(D) function path. The technical solution is no longer capable at the required ASIL D safety level. However, with the QMS functional path to manage safe emergency stops, autonomy could be allowed to continue to drive to destination after one of the two ASIL D=ASIL B(D) + ASIL B(D) paths has failed. Autonomy would disable itself after it reaches its destination and would require repair. The (D) in the ASIL B(D) means that ASIL D level hardware-software interface and board diagnostic functional safety hardware requirements apply.
All system functions from sensors to vehicle level commands are defined. The architecture of these functions is represented in a time sequence. All potential fault states for each function are defined and this produces a fault state map that is also in a time sequence. System level function/fault state detection methods are established, and these become software functional safety requirements. Each function/fault state path must be traceable to vehicle level functions, their safety goals, and to specific hazards identified in the HARA. The safety mechanisms become functional safety software requirements. Fault state arbitration is designed to respond to the first fault in a time sequence of faults. This eliminates the need to unravel a spiderweb of faults. Fault state arbitration and activation of the appropriate safety mechanism becomes a software functional safety requirement. The goal is to activate the correct safety mechanism as early as possible in any function sequence. For example, it is better to react to a driving environment perception fault than its resulting vehicle level function fault. A vehicle level function’s fault denotes the start of a potential precrash scenario.
Every system level function can be statistically evaluated by continuous univariate and statistical process control techniques. These will identify the moment that statistically significant changes in expected values or variation occurs. This means that the function is statistically different than expected. This is a change in the design’s capability. The nature of the change will be evaluated for its specific risks and be assigned appropriate safety mechanisms for activation. Rationality checks with expected functional output from alternate technical hardware/software functions can identify faults. This topic is expanded in Design for Functional Safety, The Concept Design Phase in the Functional Safety Concept chapter. It is covered in great detail with examples in the second book of this series, Design for Functional Safety, The System Design Phase.
Causes of system level faults include E/E board failures and hardware-software interface failures. There are also data transfer faults caused by connectors, wires and cables. These faults must be detected by the E/E board diagnostics and the HSI fault detection strategies. These become hardware functional safety requirements based on their ASIL assignment. When a system level software function enters a fault state it needs to request and record the fault codes of previous functions, board diagnostics, hardware software interface, and communication faults. This is a high value for remote diagnostics and resolution. All this is directly produced by 7FM Design for Functional Safety. Monitoring the E/E board/HSI faults becomes a software functional safety requirement. Software must periodically request E/E board and HSI health checks to ensure that the E/E board’s diagnostics functions are active and responsive. This is a health check of the hardware monitoring functions. This health check becomes a software functional safety requirement. The end result is that faults are detected at their earliest possible moment and the safety mechanisms are executed and completed as quickly as theoretically possible. This represents the minimum possible Fault Tolerance Time Interval. It avoids wasted time latency.
The safety mechanism can redirect the flow of functions to avoid faulty hardware/software functions. When hardware reaches a critical degradation level, autonomy can be designed to safely park the autonomous vehicle in an off-the-driving-surface location while the system can still safely control the vehicle. The fault tolerant time interval is the minimum time span from the occurrence of a fault in an item to a potential hazardous event. Fault detection and the completion of the safety mechanisms must meet FTTI requirements so hazards are avoided. This total time is divided and allocated to the series of functions. It is allocated to both hardware and software functionality.
The second part of the System Design Phase is integration. There are three levels of hardware/software integration. 1) The software is integrated with its E/E hardware and validated that it can produce the required output functions. 2) The sensors and E/E hardware are integrated and validated in its system configuration that will command vehicle level functions. 3) The system is integrated with the vehicle. The autonomous functions of the vehicle are validated at each of their applicable levels of the Mastery of Functions (figure 3.5). This will be covered in more detail during both the HARA and Functional Safety Concept chapters. It will be covered in depth in Design for Functional Safety, the System Design Phase.
The autonomous vehicle should pass all normal driving challenges on a test track (Level 3 Mastery of Function), including object and event detection before the vehicle is allowed to be driven in the autonomous mode on public roads. This is mastery of following a planned path through traffic where driving rules and right of way are followed by all vehicles and autonomy. Safety drivers would assume control any time autonomy does not respond appropriately to the driving environment. Each takeover means that vehicle level functions were inappropriate and created a precrash scenario. The cause of the limitation must be found and removed, meaning that a cause was unknowingly included in the design. All inappropriate functions are a failure-mode/fault-state. Master of Complex Scenario is where the Object and Event Detection and Responses must pass all the complex precrash scenarios identified by the HARA. Mastery of Fault Management injects faults into the system while the vehicle is in the middle of managing a complex driving scenario. This verifies that faults are detected, and safety mechanisms avoid inappropriate vehicle level functions and the autonomy can safely manage each scenario. The 7FM analysis provides a detailed fault state map and clear guidance for designing the fault injection test strategies. Functions and their faults both follow the same time sequences.
The goal of Mastery of Functions is to design functions capable of observing the driving environment and identifying the objects and events, and that are statistically capable of finding a safe and legal path that avoids all precrash scenario. The system must also be capable of object and event detection and response to reasonably expected sudden intrusions into its path (e.g., violations of right of its way).
Figure 4.9 shows that there is no statistical corner of the capability of longitudinal and lateral functions working together. The rounded corners are caused by steering while decelerating, applying brakes or accelerating. The front of the vehicle slows and turns at the same time. A capability of 1.0 produces the probability of 2,700 crashes in one million maneuvers. A capability of 2.0 produces the probability of two crashes in one billion maneuvers. These would be crashes created by autonomy following its planned path of travel, and based upon the location and motion of all objects that are involved in motion constraints.
The ground truth of the vehicle can be tracked and statistically compared to its planned path. This is variation of its actual path as compared to its planned path. Actual position, velocity and acceleration can be statistically compared to the planned position, velocity and acceleration. This includes both static and dynamic expected values with their variation. Both require that motion planning accounts for expected variation as it determines its safe path towards it goals and interacts with the driving environment to safely maneuver through traffic (vehicles, pedestrians and pedal-cyclists). Actual distance from objects as they are passed/avoided can be automatically analyzed and compared to the planned avoidance distances. This provides goals for object detection, understanding and interpreting objects, their potential intents, and predicting their current and future locations. The system then estimates time to intercept based upon the planned path and alters the path to create infinite time to intercept and a produce statistically safe stopping/passing distance. The resulting appropriate reactions of steering, acceleration, deceleration and braking follow a path that safely avoids creating a precrash scenario. This calculates and executes a safe avoidance reaction path. Highly automated vehicles (L4/L5) should always have safe avoidance solutions available to execute. This means a full safe driving path that will bring the vehicle back into its safe planned path. This way when there are unexpected intrusions, the vehicle can know how much it can safely turn and brake or accelerate to avoid intrusions into its planned path.
Capability determination is an active system level function. The variation of perception is continuously monitored. Each sensor is tracked for partial degradation (e.g., a part of the camera image is dead or degraded) and general degradation (e.g., the entire sensor image has less statistical certainty). This means that degradation of statistical certainty might be for only a portion of the driving environment. This increases measurement variation or sensor bias. When variation increases capability degrades; stopping and passing distances are increased automatically. This part of the conversation will be expanded in the HARA and its Safety Goals along with the Functional Safety Concept and its Functional Safety Requirements. The topic will be covered in depth in Design for Functional Safety, the System Design Phase.
It is obvious that statistical capability changes with conditions. Dr Edward Deming stated that no process is truly stable. There is optimal design capability, which is based upon the smallest sensor variation (measurement variation), most perfect physical response of the vehicle, and best road conditions. here is normal sensor, vehicle and driving environment variation. There is degraded sensor, vehicle response and driving environment variation. 7FM Axiom 2: Energy and degradation factors consume all material over time. Sensors degrade and reduce the distinctness of image. Sensors might develop the required distinctness of image percent match at 60m rather than the expected 100m. Static objects with known ground truth locations and object digital signature matches are stored in the MAP. The sensor’s distinctness of image coefficient has degraded from 1.00 to 0.60. This is less time to evaluate and respond. Steering, braking and acceleration/deceleration ages and changes over time. The coefficient of friction of the road and the distinctness of road parameters will change over time and between geographical locations. The statistical variation of all of these changes can be tracked and their statistical changes can be continuously updated by the autonomous system.
This means that Cpk is a dynamic and changing performance parameter. This means that motion constraints and motion planning can plan for increased variation and still achieve a minimum Cpk of 2.0. No driving environment is stable. Capability, stopping distance, passing distance, time to clear an area (acceleration) and many other dynamic driving tasks have expected statistical parameters. All of these will affect motion control/constraints and motion planning. This is coefficient learning, rather than machine learning; e.g., sensor distinctness of image coefficient, braking coefficient, steering coefficient, acceleration/deceleration coefficient, road friction coefficient, dynamic location response coefficient (e.g., to steering, acceleration, deceleration, braking, etc.). Autonomy calculations will not change. The computational answers will change as the coefficients change. All coefficients can be modeled with statistical process control. Statistical changes can be detected quickly. Statistical variation increasing or decreasing changes detected. Sudden changes of the expected coefficient are faults. The magnitude of each statistically significant change will determine its specific safety mechanism. Gradual changes can be modeled and time to fault can be calculated. All these topics will be explained in detail in Design for Functional Safety, the System Design Phase (the second book of this four books series – estimated editing phase is August 2023).
An autonomous L1 crash avoidance system might be capable of activating an emergency stop of the vehicle in response to an object that is directly in front of the vehicle. Directly in front of the vehicle has two different complexities; these are relative position and relative to the planned path. Relative position is directly in front of the autonomous vehicle as determined by a central forward sensor (middle of the window at a critical reaction distance). There is directly in front of the vehicle while following a planned path. This requires that the autonomous vehicle and object position, trajectory, velocity, and acceleration are both translated to the ground truth of a high-definition map. Validation might find that the solution has limited or no capability of predicting a crash caused by an object that is moving across its planned path. It might only recognize an object directly in the vehicle’s planned path. These limitations need to be known by both the system and drivers of the autonomous system. Emergency braking with a less than perfect object and event detection and reaction is still valuable for reducing the velocity of impact. L1 autonomy only requires that functions master the Mastery of Functions Level 1 (figure 3.5). L2 must pass Mastery of Function Level 2, functions working together. An L3 system must pass the Mastery of Function Level 3 and recognize when the driving environment is too chaotic for it to solve object and event detection and safe response. It must also safely stop the vehicle and park off the driving surface before it exits the ODD in which it has validated its functions. This is a geofence where the time/distance limits are established in the high-definition map. Motion planning must constantly evaluate and react to ODD limitations.
An L3 is a highly automated system and must warn the driver and provide sufficient reaction time for the driver to become aware of the driving environment and then take safe control of the dynamic driving task. If the L3 solution predicts that a crash will occur before normal human intervention, it should warn the driver and automatically safely park the vehicle off the driving surface. If the driver does not respond to a warning within a defined reaction period, the L3 must execute a safe controlled stop off the driving surface. The danger is that the driver will try to assume control of the safe stop before they fully understand the driving environment. This will be covered in more detail in the HARA and Functional Safety Concept Chapters. It will be covered in great detail in Design for Functional Safety, the System Design Phase. L4/L5 systems need to master all five levels within the scope of their ODDs. An L5 solution needs to know the limits of its ability to render safe dynamic driving tasks. For example, driving in some of the north New England US states has complexities that are very different to the central, southern, plain, mountains, northwest and southwest states. These regions have significantly different crash, injury and fatality rates. They are not equally complex. Some inner-city dynamic driving tasks might be so chaotic at given times of any day that the L5 autonomy could not render statistically safe commands. In this case it might place a time-based geofence and refuse to enter certain portions of the high-definition map. This refusal can be rendered at the time of destination selection. Some portions of a map might be a no-drive zone until capabilities have been achieved and the system has been remotely updated to validated system level solutions.
Part 5
Hardware Design Phase begins after the system Technical Safety Concept has defined the hardware technical safety requirements. This means that the E/E system that is being designed or purchased (SEooC) will be fully capable of supporting all computations quickly enough to produce capable OEDR solutions and satisfy its ASIL assignments. The system level analysis should provide extremely clear and stable design guidelines and requirements for HSI and E/E hardware diagnostics as well as the mechanical and electromechanical support required by hardware. Mechanical and electromechanical elements must satisfy the failure/hazard rates of the assigned ASIL.
By design, hardware must achieve its hazard rate over the length of its mission (e.g., the stated time that the system will be allowed to be active). Hardware decomposition/redundance is designed in accordance with the technical safety requirements from the system design phase. Theoretical failure rates must be verified through reliability allocation and estimations. If there are three or more independent function pathways for a given function sequence, the pathways do not require reliability to be estimated. However, the loss of one pathway requires that the system safely exits autonomy mode, unless the parallel reliability of the remaining two independent pathways have been validated and meet the ASIL hazard rate requirements. If it has been verified that two independent hardware function pathways have sufficient reliability, the system would need to exit autonomy when two of three pathways have failed.
The hardware software interface health checks/diagnostics are designed into the E/E hardware through the use of a dedicated functional safety processor that continuously monitors the E/E board and HSI health diagnostics. The diagnostics which are required depend on their assigned ASIL level requirements (e.g., A, B, C, or D). ASIL E/E board diagnostics are assigned for startup, running and turn-off-diagnostic checks. Each E/E device must define HSI resource pathways from each function’s inputs (information, command requests, energy), through all calculation, to their E/E device outputs (information, command requests, energy). Software is mapped across the E/E hardware resources from input to output. Hardware HSI resources inherits the highest level ASIL assignment from software that is processed by the hardware. Software cannot be written to interface with the E/E board and HSI diagnostics until the hardware has been designed or selected. Software cannot be mapped against the hardware until the hardware has been designed or selected. The percentage of hardware diagnostics coverage (DC) cannot be calculated until E/E board and HSI faults have been assessed and fault detection with safety mechanisms have been established. Hardware’s validation occurs before system integration and testing. The Hardware Design Phase includes Semiconductors (ISO 26262 – Part 11).
Part 6
Software Design Phase starts after the System Design Phase defines the software technical safety requirements. Software design cannot be completed until the hardware design phase identifies the hardware-software interface and board diagnostics fault detection and safety mechanisms. Complex hardware drivers and their configurations must be known in their relationship to producing and sending software-related functions (e.g., send information, send command request or send energy). This includes firmware and hardware configuration files.
Software has three levels of design. The first level is to design the functions that will become the vehicle level functions. The second level of software is the embedded software that monitors the health of each system level software function (failure mode/fault state detection). The third level of software is the embedded safety mechanisms. Embedded in this case means that it runs parallel with or in the background of the function sequences that produce the vehicle level functions. When a function faults, the potential hazard associated with the fault must be known. This means that each function fault must be rationalized against its risks of generating a vehicle level function fault state and relate to specific precrash scenarios and their hazards. Traceability is required. When the fault is detected, its safety mechanism is activated. All fault codes are given to a functional safety arbitration algorithm. It determines which fault codes are dependent on each other and which fault occurred first. The first fault code of a function sequence determines the most appropriate safety mechanism. It also determines if more than one independent failure sequence is occurring at the same time and then selects the most appropriate safety mechanism. If a resource is common to two independent function pathways, it is determined as the most likely failure point. When a system level function faults, it needs to record the health state of its inputs (e.g., previous function fault states, HSI fault states, E/E board fault states, and so on).
The first step of integration and testing is to validate the software to its specific hardware. This ensures that the intended functions meet their defined requirements. The second step of integration and testing is to join the sensors and hardware together and validate the autonomous system. This ensures that the transfer of functions from one E/E device to another is problem free. It also validates that all faults can be detected and that fault injection validates the safety mechanisms and function flow is redirected through a healthy functional path, as designed. This also validates the assign Fault Tolerance Time Intervals.
The third step of integration and testing is to join the system with the vehicle and validate the system at the vehicle level. This level ensures that the system properly communicates with and commands vehicle level functions. Integration and testing at each level will include functional capability, fault injection, degradation and reliability validation tests. All vehicle system faults, and their fault codes that can affect autonomous acceleration, deceleration, steering and braking, must be known. How each vehicle fault will degrade the expected response of the autonomous vehicle level function commands must be known. For example, in some vehicles, when two tires on one side of the vehicle have low pressure warnings, acceleration and velocity that a driver can command are limited. This means that the actual position, velocity and acceleration are lower than expected. This could create a precrash scenario. The scenario is caused when autonomy calculates safe vehicle level commands based upon the assumption of a normal vehicle response. The calculations are not based upon the derated responses that are commanded by the vehicle. Autonomy must understand and adapt to all vehicle system faults that can affect the expected vehicle level responses.
Part 7
Production, Operation, Service and Decommission determines how the Item will be produced. The system design phase will produce function input requirements and output requirements. Both will specify orientation, attachment and connection requirements that must be produced by both manufacturing and assembly operations. These manufacturing and assembly operations are safety critical and must be performed by qualified personnel who are trained in the proper use of tooling and equipment. Product produced must be inspected, tested and validated against the function’s requirements. The hardware design phase also has input and output requirements for each board function. Both will have design parameters that must be manufactured and assembled in a controlled environment and there are many industry standards of best practices that cover the manufacturing, assembly, inspection and testing required to produce and validate product that meets all quality, reliability and safety requirements. Software, drivers, configurations, calibrations, firmware and such must be produced in controlled environments and their ongoing changes must also be controlled. Production must confirm that the technical data package of every system is correct, complete and free from any quality/safety holds prior to the safety and quality release of autonomy to testing or production sales.
The validation must use defined calibration, and testing procedures and the personnel involved must be trained in the use of all testing, calibration tools and equipment. This requires procedures, instructions and records that are controlled by the IATF 16949 Automotive Quality Management System. Calibration and testing practices must meet the ISO 17025 Calibration and Lab Facility standard.
IATF 16949 covers all business practices through a product’s lifecycle. This includes all work from customer negotiations, commercial off-the-shelf offerings (SEooC), concept design, system design, verification/validation, purchasing, hardware design, software design, receiving inspection, production, inspection and testing, safety release to testing/road/sale, support/service, and autonomous decommissioning.