[Your Component Name]#
Note
Document header
[Your Component Name]
|
status: draft
security: NO
safety: ASIL_B
|
||||
.. comp:: Component Name
:id: comp__mod_temp_component_name_template
:security: YES
:safety: ASIL_B
:status: invalid
:implements: logic_arc_int__feature_name__interface_name1
:consists_of: comp__component_name_internal_1, comp__component_name_internal_2, comp__component_name_internal_3
:belongs_to: feat__feature_name
Attention
The above directives must be updated according to your Component.
Modify
documentto be your Component NameModify
idto be your Component Name in upper snake case preceded bydoc__Adjust
statusto bevalidAdjust
safetyandtagsaccording to your needs
Abstract#
[A short (~200 word) description of the component.]
Specification#
[Describe the requirements, architecture of any component.] or
How to Teach This#
[How to teach users, new and experienced, how to apply the CR to their work.]
Note
For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work.
Rejected Ideas#
[Why certain ideas that were brought while discussing this CR were not ultimately pursued.]
Note
Throughout the discussion of a CR, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions. In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued.
Footnotes#
[A collection of footnotes cited in the CR, and a place to list non-inline hyperlink targets.]
Further Documentation of the component can be found in the following sections: