An ADF’s architectural framework is composed of several standardized perspectives, typically including functional, logical, and physical architectures. As the intricacy of software and hardware incorporated in vehicles escalates, there’s a growing necessity to strategize and validate the architecture from the early stages of development to ensure safety and minimize development risks and costs. The architecture selection process involves examining different views, eventually identifying the physical function elements capable of executing the desired AD functions and the physical interfaces that can handle the required data flows.
It’s crucial to ensure that the reasoning behind the final architecture, encompassing not just requirements but also decision activities and steps, is documented for future reference and to maintain traceability. (ISO 15288:2015) This facilitates the design validation of the architecture against its specification. In subsequent iterations, architectural decisions can still be comprehended and can be preserved or modified based on the defined objective.
Main Question
Is a rationale for the chosen physical architecture put in place?
Alternative Questions:
- Is a rationale for the chosen sensor set put in place?
- Is a rationale for the chosen actuator(s) put in place?
- Is a rationale for the chosen Electronic Control Unit (ECU) put in place?
References
- ISO/IEC/IEEE (2015) 15288: System and Software Engineering – System Life Cycle Processes. Available at: https://www.iso.org/standard/81702.html (Accessed: 18 October 2023)