Example model of architectural design#

This chapter only serves as an example how an architecture could be modeled in Sphinx Needs. All the needs are required to print the views which are displayed in the Static- and Interface Views. In the actual process this files would be split into multiple different files:

Feature Architecture File#

Note

The feature and the logical interfaces are normally defined in the platform repo (features folder) and imported from there as sphinx needs objects. In this example it is defined here only, to hold the example consistent.

Feature 1 Static View
status: valid
security: YES
safety: QM

Logical Interface 1
status: valid
security: YES
safety: ASIL_B

This interface carries the feature’s primary control requests and status data. It connects the feature to the component responsible for core control, with inputs validated and errors reported through the operation results.

Logical Interface 2
status: valid
security: YES
safety: ASIL_B

This interface transfers data between the feature and the component responsible for processing it. It supports data submission and retrieval, with operation results indicating success or an applicable error.

Logical Interface 3
status: valid
security: YES
safety: ASIL_B

This interface exposes the feature’s monitoring and diagnostic information. It provides status and event data to authorized consumers and reports errors when requested information is unavailable.

Logical Operation 1
status: valid
security: YES
safety: ASIL_B
version: 1

Accepts a control request and returns whether the request was accepted or an error occurred.

Logical Operation 2
status: valid
security: YES
safety: ASIL_B
version: 1

Returns the current control status so the caller can determine the feature’s state.

Logical Operation 3
status: valid
security: YES
safety: ASIL_B
version: 1

Submits data for processing and reports whether the data was accepted or invalid.

Logical Operation 4
status: valid
security: YES
safety: ASIL_B
version: 1

Retrieves the result of a completed data-processing request or reports that no result is available.

Logical Operation 5
status: valid
security: YES
safety: ASIL_B
version: 1

Returns a health summary for the feature’s monitored components.

Logical Operation 6
status: valid
security: YES
safety: ASIL_B
version: 1

Retrieves diagnostic information for an identified component or reports that the information is unavailable.

Logical Operation 7
status: valid
security: YES
safety: ASIL_B
version: 1

Publishes a monitoring event when a component’s status changes.

Logical Operation 8
status: valid
security: YES
safety: ASIL_B
version: 1

Acknowledges a monitoring event and reports whether the event identifier is valid.

Module View File#

Module 1
status: valid
security: YES
safety: ASIL_B

This module describes the mapping and implementation of logical interfaces through their implementing components and sub-components. Logical Interface 1 is implemented by Component 1 and Sub-Component 1 (core control logic, operations 1 and 2). Logical Interface 2 is implemented by Component 2 and Sub-Component 2 (data flow and processing, operations 3 and 4).

Module 1 Static View

Module 2
status: valid
security: YES
safety: ASIL_B
version: 1

This module contains Component 3 which implements Logical Interface 3 with support and monitoring capabilities.

This is Module 2.

Module 2 Static View
version: 1

Feature or Component Architecture File(s)#

Component 2
status: valid
security: YES
safety: ASIL_B

Example Component 2 description.

Component 3
status: valid
security: YES
safety: QM

Example Component 3 description.

Component 1 Static View
status: valid
security: NO
safety: ASIL_B

Component 1_1
status: valid
security: NO
safety: ASIL_B

Sub-Component 1 implements Logical Interface 1 and provides the core control logic.

This module handles the primary operations required by the feature interface and coordinates with other sub-components through Logical Interface 2 for data exchange and synchronization.

Component 1_2
status: valid
security: NO
safety: ASIL_B

Sub-Component 2 implements Logical Interface 2 and provides data processing capabilities.

This module manages data flow, processing, and communication services required by the feature. It ensures proper data handling and supports the operations defined in the logical interfaces.

Component 1_3
status: valid
security: NO
safety: ASIL_B
version: 1

Example Sub-Component 3 description as part of Component 1.

Requirements for the Example#

Note

The stakeholder requirements shall be defined in the platform repo (stakeholder requirements folder) and imported as sphinx needs objects. Here it is defined only to hold the example together and prevent errors because the sphinx needs meta model have mandatory links to it.

Example Stkh Req
status: valid
security: YES
safety: ASIL_B
rationale: needed for archdes example
reqtype: Functional
valid_from: v1.0.0
version: 1

The platform shall provide the feature ….

Note

The feature requirements shall be defined in the platform repo (in the requirements folder of the (features)) and imported as sphinx needs objects. Here it is defined only to hold the example together and prevent errors because the sphinx needs meta model have mandatory links to it.

Example Feature Req
status: valid
security: YES
safety: ASIL_B

The feature shall provide the functionality to ….

Example Component Req
status: valid
security: YES
safety: ASIL_B
reqtype: Functional
version: 1

The component shall provide the Logical Operation 4 to get the ..