Linked Knowledge Nuggets: arrow_forward "Designing for maintainability from day one"
personAuthor: Process Fellows
Think maintenance when architecting. Clear structures, good naming, minimal duplication, and comments that explain why (not what). Maintainability isn’t added later — it’s built in.
arrow_forward "Fo(u)rces of Cybersecurity Engineering"
personAuthor: Timo Karasch,
Florian Schmitt
Cybersecurity Goals, Controls, Requirements and Threats are important forces for cybersecurity engineering. It is nearly impossible to separate them in a timely manner. In fact, they influence each other during definition.
This webinar gives a simple example of the interaction of these four forces and addresses the consistency to existing standards in Cybersecurity (ISO 21434 and Automotive SPICE for Cybersecurity). It shows a possible approach for implementation in your organization.
school
Webinar recording and slides
arrow_forward "The role of the architect"
personAuthor: Process Fellows
Not a bureaucrat, but a facilitator. Someone who translates goals into structures, moderates conflicts, aligns toolchains, and keeps the big picture stable across sprints and handovers. By the way, this is true for product related architects as well for process architects.
# PROCESS PURPOSE
The purpose is to refine the design of the (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.), (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.), consistent with the cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and to ensure they are implemented.
# PROCESS OUTCOMES
O1
The architecture of the (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.), (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.), and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) is refined.
O2 (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) are established between cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) architecture, (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) architecture and components of (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) architecture; (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) are established between cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) detailed design and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) detailed design.
O3
Appropriate cybersecurity controls are selected.
O4
Weaknesses are analyzed.
O5
Detailed design of (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) is refined.
O6 (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) are established between the (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) architecture and (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) detailed design; and (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) are established between the components of (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) architecture and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) detailed design.
O7
The agreed cybersecurity implementation is communicated to all affected parties.
# BASE PRACTICES
Imagine You Enjoy Improvement
Sponsored
At Process Fellows, we believe that progress should be both inspiring and rewarding. With a pragmatic approach and a strong team spirit, our internationally recognized experts help organizations worldwide optimize their processes and projects providing assessment, consulting, coaching, and training services.
Join us in shaping success. Because improvement isn’t just a goal—it’s an experience.
Let’s improve together!
BP1
Refine the details of the architecture. (
O1 )
The architecture of the (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.), (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.), and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) is refined based on cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.).
Note 1: Refinement here means to add, adapt, or rework (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) of the architectures.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP2
Ensure consistency and establish bidirectional traceability for cybersecurity requirements. (
O2 )
Ensure (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and establish bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) between cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) architecture, (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) architecture and components of (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) architecture. Ensure (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and establish bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) between cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) detailed design and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) detailed design.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP3
Select cybersecurity controls. (
O3 )
Select appropriate cybersecurity controls to achieve or support the cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) including an explanation of how the related risk is mitigated.
Note 2: Typically, cybersecurity controls are technical measures or other solutions to detect, counteract or mitigate cybersecurity risks.
BP4
Analyze architecture for weaknesses. (
O4 )
Analyze the architecture of the (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.), (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.), and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.), incl. interfaces and detailed design regarding weaknesses to identify vulnerabilities. Document the design decisions.
Linked Knowledge Nuggets: arrow_forward "Analysis of an architectural design"
personAuthor: Process Fellows
The analysis of an architectural design is a substantive examination of the quality of an architecture.
It should never depend on the background knowledge or experience of a single person.
For this reason, the analysis must involve a (interdisciplinary) team of experts, be based on predefined criteria and the analysis method should be documented in a comprehensible manner.
Examples of analysis criteria can be found in the Automotive Spice Guideline, but please do not hesitate to define additional criteria that are appropriate to the task and the environment!
BP5
Refine the detailed design. (
O5 )
The detailed design is refined based on the architecture of (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.).
Note 3: Refinement here means to add, adapt or rework (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) of the detailed design.
Linked Knowledge Nuggets: arrow_forward "What is the difference between a model, view and a diagram in (system) architecture?"
personAuthor: Process Fellows
In model-based development, it's essential to distinguish between the concepts of "model", "view", and "diagram", as each serves a specific purpose.
A "model" is an abstraction of reality. It represents the complete system description, but only in terms of the essential elements that are relevant to the modeling context. Irrelevant details are deliberately excluded to maintain clarity and focus. The model is considered "complete" not because it includes every possible detail, but because it captures all significant influencing factors necessary for understanding and analysis within its intended scope. Remark: This definition is applicable as well for the various disciplines, e.g. in case a model is used to define a software architecture. If needed, different modelling techniques (e.g. SysML versus UML) might be used for different disciplines.
A "view" focuses on a particular aspect of the model, such as its structure or behavior. Views are tailored to the needs of specific stakeholders, which means that certain details may be intentionally omitted. However, a view never contains more information than the model itself—it is always a subset or projection of the model. The model remains the authoritative source of truth, while views help stakeholders concentrate on what matters most to them.
A "diagram" is a visual representation of a model with respect to a specific view. It helps communicate the model’s content in a clear and accessible way. Multiple types of diagrams can be used to illustrate different views, depending on the aspect being analyzed and the audience’s needs.
BP6
Ensure consistency and establish bidirectional traceability for architecture and detailed design. (
O6 )
Ensure (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and establish bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) between the (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) architecture and (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) detailed design.
Ensure (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and establish bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) between the components of (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) architecture and (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) detailed design.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
BP7
Communicate agreed results of cybersecurity implementation. (
O7 )
Communicate the agreed results of the cybersecurity implementation to all affected parties.
Note 4: The communicated contents may include both results of the cybersecurity implementation and vulnerabilities identified within the architecture.
# OUTPUT INFORMATION ITEMS
13-52
Communication Evidence (
O7 )
All forms of interpersonal communication such as:
e-mails, also automatically generated ones
tool-supported workflows
meeting, verbally or via meeting minutes (e.g. daily standups)
podcast
blog
videos
forum
live chat
wikis
photo protocol
Used by these processes:
SEC.1 Cybersecurity Requirements Elicitation
SEC.2 Cybersecurity Implementation
SEC.3 Risk Treatment Verification
SEC.4 Risk Treatment Validation
Used by these process attributes:
PA2.1 Performance Management
13-51
Consistency Evidence (
O2, O6 )
Demonstrates bidirectional (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) between artifacts or information in artifacts, throughout all phases of the life cycle, by e.g.:
tool links
hyperlinks
editorial references
naming conventions
Evidence that the content of the referenced or mapped information coheres semantically along the (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) chain, e.g., by
performing pair working or group work
reviewing by peers, e.g., spot checks
maintaining revision history in documents
providing change commenting (via e.g., meta-information) of database or repository entries
Note: This evidence can be accompanied by e.g., Definition of Done (DoD) approaches.
Used by these processes:
SEC.1 Cybersecurity Requirements Elicitation
SEC.2 Cybersecurity Implementation
SEC.3 Risk Treatment Verification
SEC.4 Risk Treatment Validation
17-52
Cybersecurity controls (
O3 )
Technical solutions to prevent, detect, or mitigate cybersecurity risks
Associated to one or more cybersecurity (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.)
Used by these processes:
SEC.2 Cybersecurity Implementation
04-52
Hardware Architecture (
O1, O2 )
Describes the initial floor plan and the overall (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) structure
Identifies the required (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) components
Includes the rationale for chosen options of (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) architecture
Identifies own developed and supplied (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) components
Identifies the required internal and external (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) component interfaces
Specifies the interfaces of the (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) components
Specifies dynamic behavior
Identifies the relationship and dependency between (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) components
Describes all (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) variants to be developed
Describes power supply, thermal and grounding concepts
Used by these processes:
SEC.2 Cybersecurity Implementation
04-53
Hardware Detailed Design (
O2, O5 )
Describes the interconnections between the (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) parts
Specifies the interfaces of the (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) parts
Specifies the dynamic behavior (examples are: transitions between electrical states of (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) parts, power-up and power-down sequences, frequencies, modulations, signal delays, debounce times, filters, short circuit behavior, self-protection)
Describes the conclusions and decisions based on e.g. analysis reports, datasheets, application notes
Describes the constraints for layout
Used by these processes:
SEC.2 Cybersecurity Implementation
04-04
Software Architecture (
O1, O2 )
Justifying rationale for the chosen architecture
Individual functional and non-functional behavior of the (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.)
Settings for (Application parameter = An application parameter is a software variable containing data that can be changed at the system or software levels; they influence the system’s or software behavior and properties. The notion of application parameter is expressed in two ways:
The specification (including variable names, the domain value range, technical data types, default values, physical unit (if applicable), the corresponding memory maps, respectively).
The actual quantitative data value it receives by means of data application.
Application parameters are not requirements. They are a technical implementation solution for configurability-oriented requirements.) (being a technical implementation solution for configurability-oriented (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.))
Technical characteristics of interfaces between (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.), e.g.:
Synchronization of processes and tasks
Programming language calls
APIs
Specifications of SW libraries
Method definitions in object-oriented classes or UML/SysML interface classes
Callback functions, “hooks”
Dynamics of (Software component = Software component in design and implementation-oriented processes:
The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model.
Software component in verification-oriented processes:
The implementation of a SW component under verification is represented e.g., as source code, object files, library file, executable, or executable model.) and (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) states, e.g.:
Logical (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) operating modes (e.g. start-up, shutdown, calibration, diagnosis)
Intercommunication and priority
Time slices and cycle time
Interrupts with priorities
Interactions between components
Explanatory annotations (e.g. with natural language) for single (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) or entire models
Used by these processes:
SEC.2 Cybersecurity Implementation
04-05
Software Detailed Design (
O2, O5 )
(Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) of a (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) detailed design:
Control flow definition
Format of input/output data
Algorithms
Defined data structures
Justified global variables
Explanatory annotations, e.g. with natural language, for single (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) or entire diagrams/models
Examples for expression languages, depending on the complexity or criticality of a (Software unit = Software unit in design and implementation-oriented processes:
As a result of the decomposition of a software component, the software is decomposed into software units which are a representation of a software element, which is decided not to be further subdivided and that is a part of a software component at the lowest level, in a conceptual model
Software unit in verification-oriented processes:
An implemented SW unit under verification is represented e.g., as source code files, or an object file.):
natural language or informal languages
semi-formal languages (e.g. UML, SysML)
formal languages (e.g. model-based approach)
Used by these processes:
SEC.2 Cybersecurity Implementation
04-06
System Architecture (
O1, O2 )
A justifying rationale for the chosen architecture
Individual behavior of (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.)
Interrelationships between (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.)
Settings for (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) parameters (such as (Application parameter = An application parameter is a software variable containing data that can be changed at the system or software levels; they influence the system’s or software behavior and properties. The notion of application parameter is expressed in two ways:
The specification (including variable names, the domain value range, technical data types, default values, physical unit (if applicable), the corresponding memory maps, respectively).
The actual quantitative data value it receives by means of data application.
Application parameters are not requirements. They are a technical implementation solution for configurability-oriented requirements.))
Manual/human control actions, e.g., according to STPA
Interface definitions
Technical characteristics of interfaces for relationships between two (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.)
Interfaces between (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.), e.g.:
bus interfaces (CAN, MOST, LIN, Flexray etc.)
thermal influences
(Hardware = Physical equipment used to process, store, or transmit computer programs or data.)- (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) interfaces (HSI)
electromagnetic interfaces
optical interfaces
(Hardware = Physical equipment used to process, store, or transmit computer programs or data.)-mechanical interfaces (e.g., a cable satisfying both mechanical and electrical (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.), housing interface to a PCB)
(Hardware = Physical equipment used to process, store, or transmit computer programs or data.)-mechanical interconnection technology such as connectors, pressfit
creepage and clearance distances
Fixations such as adhesive joints, screw bolts/fitting, riveted bolts, welding
(System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) interfaces related to EE (Hardware = Physical equipment used to process, store, or transmit computer programs or data.), e.g.:
analogue or digital interfaces (PWM, I/O) and their pin configurations
SPI bus, I2C bus, electrical interconnections
placement, e.g., thermal interfaces between (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) (heat dissipation)
soldering
creepage and clearance distances
Interfaces for mechanical engineering, e.g.:
friction
thermal influences
tolerances
clutches
fixations such as adhesive joints, screw bolts/fitting, riveted bolts, welding
forces (as a result of e.g., vibrations or friction)
placement
shape
A (Hardware = Physical equipment used to process, store, or transmit computer programs or data.)- (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) interface, e.g.:
connector pin configurations and floating IOs for µCs/MOSFETs
signal scaling & resolution to be reflected by the application (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.)
Mechanical- (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) interfaces, e.g.:
mechanical dimensioning
positioning of connectors
positioning of e.g., hall sensors in relation to the bus-bar
tolerances
Dynamics of (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) and (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) states:
Description of the (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) states and operation modes (startup, shutdown, sleep mode, diagnosis/calibration mode, production mode, degradation, emergency such as “limp-home”, etc.)
Description of the dependencies among the (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) components regarding the operation modes
Interactions between (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.) (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) such as inertia of mechanical components to be reflected by the ECU, signal propagation and processing time through the (Hardware = Physical equipment used to process, store, or transmit computer programs or data.) and (Software = Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.) and e.g., bus (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.)
Explanatory annotations, e.g., with natural language, for single (Element = Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.) or entire diagrams/models
Used by these processes:
SEC.2 Cybersecurity Implementation
15-50
Vulnerability analysis Evidence (
O4 )
Identifies:
ID
description
(Attack path = Set of deliberate actions to realize a threat scenario.) concerned
(Attack feasibility = Attribute of an attack path describing the ease of successfully carrying out the corresponding set of actions.) (e.g. CVSS (Common (Vulnerability = Weakness that can be exploited as part of an attack path.) Scoring (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.)) rating)
SEC.2
Cybersecurity Implementation
