Concept Description#
Architecture Process
|
status: valid
|
||||
In this section a concept for the architecture design will be discussed.
Inputs#
Use cases which require the architectural design?
Who needs which information?
Which standard requirements need to be fulfilled
Use Cases which require architectural information#
Contribution Request
Platform High Level Architecture
Graphical Feature Description
Safety Analysis
Dependent Failure Analysis
the interaction of the components with each other
Qualitative safety analysis
decomposition of the architectural element under analysis
interfaces within the architectural element under analysis (including their AoUs)
usage of the components (interface of the component under analysis itself)
allocate safety requirements to architectural elements
Security Analysis
TBD
Safety Planning
Decomposition into modules and components for the safety planning
Security Planing
TBD
Platform SW Development
Interfaces of own component and their respective contracts (including dynamic architecture) which need to be implemented
Interfaces of the interacting components which are used to obtain required information (including AoUs)
White Box view of the component itself
Testing
Use cases for the component including their AoUs
On component level an overview of the actual interfaces
All the interfaces and AoUs of the interacting components which need to be provided for a black box test
Software Integration
components which need to be integrated
dependencies for the integrated components including their configuration
order and task scheduling for all components
Application SW Development
public interfaces which are provided at the top level including their contracts
expected sequence of the single operations
a detailed api description of the interface
Project Management
High Level Architecture for project structuring and planning
Requirements based on standards#
Additionally also standards specify requirements towards the architectural design:
ISO26262
ASPICE
ISO21434
Their requirements are linked via the guidances.
Definition of architectural viewpoints#
In this section following questions shall be answered:
Which architectural viewpoints can we derive from the inputs?
Which architecture attributes are required?
How do the different viewpoints correlate to each other?
Based on the inputs two architectural levels are defined.
Feature View#
Static View#
The first viewpoint is named as feature architecture. It displays the SW modules (= top level SW components) which are required to realize the feature including their interactions. Also the logical interfaces and the interaction between the feature and the user are included in this view. On this architectural level the feature requirements shall be allocated. An example for the static architecture is shown here:
Feature 1
|
status: valid
security: YES
safety: QM
|
||||
|
|||||
Dynamic View#
The next chart shows the dynamic behavior of the feature including the interaction of its modules with the user. Following scenarios should be included:
important use cases or features: how do components execute them?
interactions at critical external interfaces: how do components cooperate with users and neighboring components?
operation and administration: launch, start-up, stop
successful use cases
error and exception use cases
Fig. 17 Dynamic Feature Architecture#
Interface View#
On the feature level only logical interfaces shall be displayed. This means that only logical names shall be provided for both the interface and the operations within. Those logical interfaces shall be connected to component interfaces on the module view.
Logical Interface 1
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
SW Module View#
A SW module can rather be defined as a top level component view. Since a SW module view can also be provided by the top level SW component view no additional view is required here.
Component View#
Static View#
The second viewpoint is named as component architecture and describes the implementation of the functionalities in a white-box view of the platform. It describes the structural decomposition of the SW components into lower level SW components. In the S-CORE project this viewpoint provides more detailed information concerning the respective interfaces of a component. If a SW component interacts with a different component it is also included via a use relationship in the diagram. An example of the component architecture is displayed here:
Component 2
|
status: valid
security: NO
safety: ASIL_B
|
||||
|
|||||
The lower level components are optional and rely on the complexity of the component. Thus there is no graphic representation required for it.
Dynamic View#
The dynamic view of the component architecture shows the order of the interactions between the respective components. It is displayed via relations to the interface operations which are provided or used by each component.
Fig. 18 Dynamic Component Architecture#
Interface View#
The component interface view shows the actual interfaces of the component. Also links to their corresponding logical interfaces are displayed in this view:
Component Interface 1
|
status: valid
security: NO
safety: ASIL_B
|
||||
|
|||||
Platform View#
Although it is required to create a DFA on platform level no additional view is required for this architectural level:
Features should be defined in a such way that they are independent of each other. Any dependencies should be displayed via common components in the feature view.
The feature set depends on the feature selection on platform level. This means that this view would depend highly on the selection of features which an integration choses to integrate on platform level. Thus this view would need to be generated based on the feature selection.
Specification of the architectural design#
The architectural design shall be modeled with the help of static, dynamic and interfaces at each defined level. For the description a natural language, diagrams or a semi-formal language (UML) shall be used.
The architectural elements itself including their correlations shall be modeled in a database like approach. Therefore following architectural elements shall be used:
Static view#
The static view shows the building blocks of the architecture. It shall be completely modeled in sphinx needs. Following elements are defined:
Element |
Sphinx Needs Directive |
Code Template |
|---|---|---|
Feature Architecture |
feat_arc_sta |
feat_arc_sta_t |
Component Architecture |
comp_arc_sta |
comp_arc_sta_t |
Dynamic view#
The dynamic view describes the concrete behavior and interactions of the building blocks in form of use cases which were described above.
The dynamic view shall be modeled partly in Sphinx Needs and PlantUML. The components itself shall be generated from the sphinx needs model into the PlantUML diagram. The dynamic relations between the component and the interfaces shall be modeled in PlantUML as it would be a huge effort to model the dynamic behavior in sphinx needs and would not provide any additional benefit.
Element |
Sphinx Needs Directive |
Code Template |
|---|---|---|
Dynamic Feature Architecture |
feat_arc_dyn |
feat_arc_sta_t |
Dynamic Component Architecture |
comp_arc_dyn |
comp_arc_dyn_t |
Interface view#
The interface view focuses on the interfaces of the components and shows the operations within.
(Logical) Interface |
feat_arc_int |
feat_arc_int_t |
|---|---|---|
(Logical) Interface Operation |
feat_arc_int_op |
feat_arc_int_op_t |
(Real) Interface |
comp_arc_int |
comp_arc_int_t |
(Real) Interface Operation |
comp_arc_int_op |
comp_arc_int_op_t |
Relations between the architectural elements#
The traceability between the architectural elements itself shall be established by modeling the elements in the docs-as-code tool. Here a “clickable” architecture can be generated which allows an easy tracing through the element tree. The previously introduced architectural components shall be connected by using following relations:
Fig. 19 Definition of the Metamodel for Architectural Design#
Attributes of the architectural elements#
Since the architecture should be modeled in Sphinx Needs the corresponding attributes need to be defined. On the top level we can distinguish between attributes which need to be filled manually and attributes which are generated during the sphinx-docs build.
Following attributes need to be filled manually for each requirement:
Attribute |
Description |
|---|---|
Unique ID |
The naming scheme for the UID is defined here: Architecture attribute: UID (gd_req__arch__attribute_uid) |
Title |
The title of the architectural element shall be expressive. |
Status |
Status of the architectural element [valid,invalid] |
Safety |
This attribute describes the impact of the architectural element on functional safety. Currently only following values are defined [QM, ASIL_B, ASIL_D]. Other values are not required at the moment as ASIL decomposition is not used so far. |
Security |
This attribute describes if the architectural element has any impact on the security of the platform. [YES,NO] |
Fulfils |
With this attribute the relations to the corresponding requirements shall be described |
For creating architectural elements also templates for each level are available:
Feature Architecture: Feature Architecture Templates
Component Architecture: Component Architecture Temp...
Establish traceability between requirements and architectural elements#
During the architectural design process all feature and component requirements shall be allocated to a single architecture element at the corresponding level via the attribute fulfils.
Reviews of the architecture#
Some of the checks cannot be performed automatically. Therefore a manual inspection of the architecture is needed. The architecture review itself is included in the PR review which is triggered if a contributor wants to commit code to the main line. For this review a checklist is available: Architecture Inspection Che... (gd_chklst__arch__inspection_checklist).