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
|
status: valid
security: YES
safety: QM
|
||||
This is the example feature which shall normally defined in the platform repo. |
|||||
Feature 1 Static View
|
status: valid
security: YES
safety: QM
|
||||
|
|||||
Logical Interface 1
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Interface 1 provides the primary control and communication interface for the feature. It is implemented by sub-component 1 which handles the core functionality. |
|||||
Logical Interface 2
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Interface 2 provides support for data processing and communication between sub-components. It is implemented by sub-component 2 which handles data flow and processing operations. |
|||||
Logical Interface 3
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Interface 3 provides additional support and monitoring capabilities for the feature. |
|||||
Logical Operation 1
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Operation 2
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Operation 3
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Operation 4
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Operation 5
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Operation 6
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Operation 7
|
status: valid
security: YES
safety: ASIL_B
|
||||
Logical Operation 8
|
status: valid
security: YES
safety: ASIL_B
|
||||
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
|
||||
This module contains Component 3 which implements Logical Interface 3 with support and monitoring capabilities. This is Module 2. |
|||||
Module 2 Static View
|
|||||
|
|||||
Feature or Component Architecture File(s)#
Component 1
|
status: valid
security: YES
safety: ASIL_B
|
||||
Example Component 1 description. |
|||||
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
|
||||
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
|
||||
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
|
||||
The component shall provide the Logical Operation 4 to get the .. |
|||||