top of page

Architectural Design

​

Architectural design is the (typically) recursive decomposition of an “item” (including its interfaces) into architectural elements[1]. Each of the architectural elements are labelled.  The requirements are then decomposed according to the architecture and assigned to the architectural elements.  It is recursive in that an architectural element may then become an “item” for further decomposition.

At the end of the architectural design phase, there will be

  • A defined architecture with multiple layers of decomposition

  • Definitions of variants of the architecture that are needed for integration & test​​

  • A decomposition of requirements and interfaces according to the architecture

  • Attributes in the requirements database that can be used to filter based on the name of architectural elements​​

 

[1] This implies that the decomposed interfaces are themselves architectural elements, and that the interfaces of the system boundary diagram should have associated requirements.

1.  Sketch potential architectures (optional)

Where more than one architecture is being considered, the potential architectures are sketched and rated according to project specific criteria.  These criteria may include, for example, reuse of items, technical complexity, required resources for development, availability of tools/facilities and so forth.  This step is marked as optional as there are many situations where only one architecture is a technically viable solution.  In this case, it is acceptable to just make a statement such as “this architecture is based on engineering judgement/experience” or “This architecture  has been derived from a similar architecture in previous projects”.  What is certainly not acceptable, is to retrospectively re-create this step as evidence for auditors; it is regarded as better to have no evidence than have fabricated evidence.

2.  Define preferred architecture

The preferred architecture is documented using the project diagrammatic tool(s).  The top level of the architecture should be the boundary diagram from the system definition process with each architectural element forming the basis of the next level for decomposition.

It is normal that the architecture will evolve as people’s ideas solidify during development.  This should be managed within the project database and its version control system, including any reasons for the changes to the architecture.

It is also likely that there will be different views of the same architecture in the project.  For example, there may be a process control and instrumentation as well as the hierarchical system decomposition.   To minimize the number of different views (and hence simplify maintenance of diagrams), it is recommended to use diagrammatic tools that permit alternate views of the same architecture and, where appropriate, have layers that can be enabled/disabled to hide/show details of a diagram.  For example, a system level diagram that shows low voltage, high voltage and communications connections in a single diagram would be much easier to understand if these were on different layers of the same diagram.

If there are variants in the architecture (for example, features that are only some vehicle models), the variants should also be provided.

3.  Define architectural variants for integration & test

Architectural variants are defined that will be specifically required for integration and test of items.  This integration and test may cover systems,  software, electronics hardware and other disciplines.  Examples of architectural variants could include items such as:

  • Hardware-in-the-Loop (HiL) test systems for testing ECUs + Software before vehicle level integration / test

  • Input-output (IO) test systems for ECU + Base Software tests

    • Ideally these architectural variants could also be used for other testing such as parametric, powered thermal cycling, DV, etc., where a powered and functioning item is required​

  • Model-in-the-Loop (MiL) test systems for Application Software test

  • Software stubs / dummy modules​

​

These architectural variants should be defined at this stage to allow time for development / procurement of these items.

Note: this step is missing in ASPICE

​

bottom of page