Feature Architecture#

Note

The complete feature architecture template as shown here is intended to document the idea about the architecture of a feature (if needed) when a CR is created. After the CR is granted, it is moved and further detailed / maintained in the module where the feature resides. See module template documentation. Only the logical interfaces remains in the feature architecture platform documentation, as they are relevant for the overall platform architecture. The detailed architecture of the feature is documented in the module documentation, and the logical interfaces are linked from there to the platform documentation. This is to avoid that the platform documentation becomes too detailed and hard to maintain, while still providing the necessary information about the feature architecture in the platform documentation. Depending from the project it might be that in the reference integration of the platform the full feature architecture including the implementation of the features and its components becomes visible in the platform documentation. See Deployment example.

[Your Feature Name] Architecture
status: draft
security: NO
safety: ASIL_B
tags: template
version: 1
realizes: wp__feature_arch
doc__feature_name_architecture
Generic Document

Attention

The above directive must be updated according to your Feature.

  • Modify Your Feature Name to be your Feature Name

  • Modify id to be your Feature Name in upper snake case preceded by doc__ and followed by _architecture

  • Adjust status to be valid

  • Adjust safety and tags according to your needs

Overview#

<Brief summary>

Description#

<General Description>

<Design Decisions - For the documentation of the decision the Decision Record Template can be used.>

<Design Constraints>

Requirements#

.. needtable:: Overview of Feature Requirements
   :style: table
   :columns: title;id
   :filter: search("feat_arch_sta__archdes$", "fulfils_back")
   :colwidths: 70,30

No needs passed the filters

Rationale Behind Architecture Decomposition#

Mandatory: A motivation for the decomposition

Note

Common decisions across features / cross cutting concepts is at the high level.

Static Architecture#

The live feature architecture template snippets are maintained in the module template documentation.

Logical Interfaces#

.. logic_arc_int:: Interface Name
   :id: logic_arc_int__feature_name__interface_name1
   :security: YES
   :safety: ASIL_B
   :status: invalid
   :version: 1
   :fulfils: feat_req__feature_name__some_title
   :included_by: feat__feature_name

   <General Interface Description with description of the interface and its
   purpose. The description should be as detailed as possible to provide a
   clear understanding of the interface's role within the feature
   architecture and the input/output interactions and data (on high level)
   it supports. Also, include any relevant information about the
   interface's design decisions (if not already covered in the general
   description of the feature), constraints, and any specific requirements
   (for example timings) it have to fulfill. This will help in
   understanding the rationale behind the interface's design and its
   contribution to the overall feature architecture. Please describe also
   the intended error handling mechanisms on high level, security
   considerations, and any other relevant aspects that are crucial for the
   interface's implementation and usage within the feature architecture.>

   .. needarch::
      :scale: 50
      :align: center

      {{ draw_interface(need(), needs) }}

.. logic_arc_int_op:: Operation
   :id: logic_arc_int_op__feature_name__operation
   :security: YES
   :safety: ASIL_B
   :status: invalid
   :version: 1
   :included_by: logic_arc_int__feature_name__interface_name1

   <General Operation Description with description of the operation of the
   interface and its purpose. The description should be as detailed as
   possible to provide a clear understanding of the operation's role within
   the interface and the input/output interactions it supports. Also,
   include any relevant information about the operation's design decisions,
   constraints, and any specific requirements it fulfills. This will help
   in understanding the rationale behind the operation's design and its
   contribution to the overall feature architecture. Please describe also
   the intended error handling mechanisms on high level, security
   considerations, and any other relevant aspects that are crucial for the
   operation's implementation and usage within the feature architecture.