[MBSE-Method] #3. SysCARS methodology

This post is based on the paper “SysML for embedded automotive systems: SysCARS methodology, Jean Denis PIQUES”.

SysCARS (System Core Analyses for Robustness and Safety) is a methodology developed by Valeo that is designed to enable system designers to perform modeling activities sequentially and efficiently using SysML. This methodology is very useful for system engineers involved in developing embedded systems for automotive electronics.

This blog aims to provide practical information for such system engineers. Therefore, in this post, I will briefly introduce the paper.

SysCARS workflow

The SysCARS methodology begins with the system engineering process, analyzes the project context, considers the system to be developed as a ‘black box’, and proceeds with gradual detailing until the characteristics of the internal components (or system elements) are specified. It’s possible. This methodology is broadly divided into five steps:

1. Stakeholder needs definition
2. Requirements analysis
3. Logical architecture design
4. Physical architecture design
5. Components needs definition

Each step concludes as follows:

• Traceability analysis verifies the consistency and completeness of the activities performed and the artifacts created.
• Automatically generate activity summary documents (stakeholder requirements document, system requirements document, system design document, component requirements document).

In practice, several steps can be performed simultaneously, resulting in iterative and complementary refinements.

Additionally, the diagram types used in each step are indicated by the SysML abbreviation and are associated with each activity: Block Definition Diagram (BDD), Internal Block Diagram (IBD), Use Case Diagram (UCD), Sequence Diagram (SD), and State. Machine Diagram (STM), Activity Diagram (AD).

Two types of optimized workflows

• SysCARS-XS (Extended Stream): All activities are performed for innovative products, especially investigating multiple physical architectures and trade-off analysis.
• SysCARS-CS (Core Stream): Activities marked with gray boxes will not be performed for carryover products.

In what follows, only the SysCARS-CS simplified workflow is presented for clarity.

---

1. Stakeholder needs definition

Perhaps the most important step in the system development process is gathering initial requirements to ensure the goals that the system under development should pursue. At this stage, all analyzes are performed from the perspective of external users of the system, and the system is considered a ‘black box’. The main steps are:

1. Identify the needs of all stakeholders
2. Define the boundaries of the system and relevant external actors
3. Identify and describe operational use cases
4. Identification of user-level operating mode
5. Connect operational use cases and stakeholder requirements

The output of this step is the “Stakeholder Needs Document” (SND), which contains a synthesis of all activities performed. This document provides an important baseline for the system design and development process by clearly reflecting the expectations and needs of stakeholders in relation to the goals of the project.

1.1 Elicit stakeholder requirements (REQ)

All individuals and organizations that may have an interest in the system are potential sources of requirements and must be identified prior to any other activity. The important point is that stakeholder needs should describe the services expected by users of the system, not how these needs will be met.

Manage the origin of requirements:

• Stakeholder requirements sources are managed outside of the SysML model, within requirements documents or specific databases.
• Particularly important is capturing mission-level performance requirements and expected performance measures, which are later used to select the optimal one among candidate solutions.

Integration of requirements into SysML:

• Stakeholder requirements must be imported into a SysML Requirements object with all relevant fields (using the same identifier).
• A gateway mechanism such as Reqtify is required to perform one-way synchronization from external data to SysML when source data changes.

Extensions to the SysML requirements format:

• Since the standard SysML requirements format is very limited, we use the extension mechanism of stereotypes to add new specific properties (i.e. tags) to track additional information arising from the analysis performed during derivation.
• Particularly important tags attached to requirements during the elicitation phase are devoted to classifying the requirements into one of three categories: user-related, system-related, or component (i.e. system elements)-related. This value later determines at which modeling level the requirement will be addressed.

1.2 Contextual Analysis (BDD)

A system context diagram represents the immediate environment of a system and provides initial information about the boundaries of the system and the interactions between the system and external systems and users.

1. Identification of the different stages of the system life cycle: For each life cycle stage, from manufacturing to recycling, one SysML block definition diagram is declared to model the relevant operational context.
2. Show the system itself in the center of the diagram: The system appears in the center of the diagram as a single black box SysML block.
3. Represent all currently known interaction partners: Represent interaction partners using SysML actor objects. Actors refer to roles played by external elements with which they are interacting, rather than by specific individuals or systems.
4. Representation of interaction between actors and systems: Represented as SysML associations. The purpose is to identify basic information to help determine the service requested on the system, not to provide technical details of this service.
5. Document constraints for the service: Documented in the description field of the association.

Defining a context diagram may seem obvious, but in reality, the process of finding actors can lead to very fruitful discussions that define responsibilities among various stakeholders. These discussions play an important role in the early stages of a project and can have a significant impact on the direction of system design and development.

1.3 Identify context scenarios (UC, SD)

Contextual use cases represent the services expected by system users (humans or other systems) and are a key input to the requirements analysis phase. Contextual use cases help refine stakeholder expectations, allowing for more detailed identification of system requirements. Contextual use cases are identified by starting from a context diagram and asking actors what they want from the system, particularly in relation to their roles and the incoming information flow.

Details of use cases and scenarios:

• Use Case: Always references at least one actor, started by an external trigger and ended by a user result.
• Each stage of the system life cycle: Many use case diagrams for each stage are explained.
• Scenario: A group of scenarios performed by the same key actors, starting from the same starting point and leading to the same ending point. This scenario describes a sequence of interactions and actions, starting with the same antecedent conditions (triggers) and ending with the same subsequent conditions (outcomes). Preconditions and postconditions correspond to the modes (i.e. user states) of the user mode state machine, which will be discussed in the next chapter.

Representation of the scenario:

• Scenarios are described using SysML sequence diagrams. Interactions within a scenario are declared as context events, which are later used to define transition conditions between states in the user mode state machine.
• Each sequence diagram is primarily established to identify system interactions. The sequence diagram is further refined during the requirements analysis phase to identify the functions performed by the system.

This step is essential to accurately identify and define system requirements and provides an important foundation for subsequent design and development work.

1.4 User Mode Identification (STM)

A mode characterizes a situation in the life of a system in which certain expected behaviors can be defined. It represents the state invariance of the system, its state as seen from an external user perspective (i.e., it is about the service provided to the user and not how the system performs this service). The goal is to derive a unique state machine that aggregates all identified modes (states) and key transitions (events) in the context scenario. Therefore, setting up a user-mode state machine is an iterative process that is closely linked to and intersects with the identification of context scenarios described in the previous chapter.

Purpose and Method:

• Purpose: Describe the actions involved in any context scenario, and summarize them into a unique state machine.
• Method: This state machine is owned by a context block associated with the overall black box system.

The configuration of the user-mode state machine clearly defines how the system should react in certain situations, which plays an important role in the design and implementation phases of the system. Each mode provides important criteria for determining how the system should respond to different user needs and situations. This process allows the system to respond more flexibly and effectively to user needs.

1.5 Contextual traceability verification (REQ)

Stakeholder (or initial) requirements refer to statements that define expectations for the system, such as mission objectives, environment, constraints, and performance measures, from the perspective of the users of the system. To ensure that the needs of all stakeholders are covered by the contextual use cases, corresponding traceability links must be established between SysML use cases and requirements.

Traceability analysis method:

• Use requirements tables and traceability matrices: Verify the completeness of the model using specific features of Artisan Studio tools. These tables and matrices clearly show the connections between use cases and requirements, allowing you to understand how each requirement is met by the context use case.
• Connected by inductive relationships: According to the traceability data model presented in Chapter 5.3, all requirements characterized as user-related must be covered by corresponding contextual use cases, and are connected by inductive relationships.

This process plays an important role in ensuring that stakeholder expectations and requirements are appropriately reflected at all stages of the project. Traceability verification is an essential element of project management and quality assurance, ensuring that the design and implementation of the system is progressing in a way that meets the needs of stakeholders.

1.6 Stakeholder Needs document

The final step is to automatically generate a document that creates a synthesis of all modeling activities performed during the stakeholder requirements definition phase. This document is named “Stakeholder Requirements Document” (SND).

Document creation process:

• Automatically generated: Automatically generates documents by synthesizing all relevant data and activities using a modeling tool or system.
• Purpose of Document: This document serves to clearly demonstrate to the project team, stakeholders, and other partners involved how the initial needs and expectations of stakeholders were reflected in the modeling process.
• Usability: The SND can be used as a reference document during later design and development stages, acting as a standard to ensure that the project’s requirements are being properly met.

This document provides a comprehensive compilation of all essential information and requirements collected during the early stages of the project, allowing the project team to proceed with clear guidance and direction.

---

2. Requirements analysis

The purpose of the requirements analysis phase is to analyze the previously collected input and transform it from a problem statement into an abstract solution. This step is performed from the perspective of the system designer, with the system still considered a ‘black box’. The main steps are:

1. Precisely describe the system’s interface with external actors: This step clearly describes how the system will interact with external actors.
2. Develop and elaborate the system use case: This step develops and elaborates the system’s use case, defining the key functions and tasks the system must perform.
3. Identification of system-level operating states: Identify the operational states that define how the system will behave in various situations.
4. Develop and elaborate system requirements into external functional and interface descriptions: This step further develops and defines the functional requirements and interfaces of the system.
5. Link system functions and interfaces to system requirements: Connect how each function and interface matches with the overall requirements of the system.

result:

• The output of this phase is a “System Requirements Document” (SyRD), which summarizes all activities performed. This document serves as a basic reference for moving to the next stage of the project.

This step is an important step in specifically defining the performance and functionality of the system. By ensuring that each element is well integrated with the overall goals of the system, it establishes a solid foundation for effective system design and development.

2-1. External Interface Identification (IBD)

The goal of the external interface identification step is to provide more detailed information about the interaction flow between actors and the system (still considered a ‘black box’). In this step, the physical external interfaces of the system are described using internal block diagrams. This diagram represents the system blocks and all interacting actors.

1. Define system blocks: Define system blocks as specializations of the context blocks studied in the previous step (Stakeholder need definition step). This helps you keep track of previously performed analyses.
2. Specify the type of data flow: Each port must have a SysML item type or flow specification associated with it to specify the type of data flow allowed.
3. Description of different contexts of use: Several internal block diagrams are defined to describe different contexts of use.
4. Definition of multiple diagrams for the same context of use: Multiple internal block diagrams can be defined for the same context of use, each diagram corresponding to a specific kind of interface (e.g. mechanical, electrical, data processing bus, etc.) do.

This approach is particularly useful for facilitating information sharing with related disciplines and preventing interface diagram overload. Each interface plays an important role in the overall design and functionality of the system and lays the foundation for effective system integration.

2-2. System scenario detailing (SD)

The purpose of this step is to detail the context-level scenario to identify the key services or functions that the system must perform. This activity is essentially similar to external feature analysis.

1. Preserve and replicate context sequence diagrams: Obtain an initial system sequence diagram by retaining and replicating the context sequence diagram to trace the analysis performed at previous context levels. The same approach is adopted between context use case diagrams and system use case diagrams.
2. Replacing context blocks with system blocks: After replacing context blocks with system blocks, the system sequence diagram is supplemented with the functions to be performed by the system. The system is still considered a ‘black box’.
3. Function Modeling: As shown in the figure below, functions are modeled as SysML operations and attached to the lifelines of system blocks.
4. Declaration of Interactions and System Events: Interactions within a scenario are declared as existing context events or new system events, which are then used to define the conditions for transitions between states of the system state machine.
5. Start and end points of scenarios: The start and end points of each scenario correspond to the states of the system state machine.

This process better defines the key services and functions that the system will perform, which provides important information for system design and integration. Each function of the system is fine-tuned to meet user requirements, contributing to increased efficiency and effectiveness of the overall system.

2-3. System State Identification (STM)

The purpose of this step is to summarize and describe all actions involved in the system scenario into a unique state machine. This state machine is owned by a system block that describes the entire ‘black box’ system. A system state machine is not necessarily a refinement of a user-mode state machine; new substates may be added, existing states may be removed, or completely different structures may be defined.

State machine setup procedure:

1. Iterative process: The setup of the system state machine is an iterative process that is closely linked and intersects with the detailing of the system scenario described in the previous chapter.
2. Clear definition of transitions and states: Once the transitions and states of the system state machine are well defined, defining in which states the key functions identified in the system scenario will be triggered becomes a particularly important step.
3. Call the related action: This is simply done by calling the related action using the Do property of that state.

System state machine as the central element:

• The system state machine becomes a central element of the system model, allowing the behavior of the system to be simulated and its behavior evaluated for verification purposes. This helps ensure that the system design performs as expected in a real-world operational environment.

This course clearly defines how the system should react in various situations and establishes a solid foundation for effective system integration and operation.

2-4. System Requirements Traceability Verification (REQ)

System-level requirements are described within the SysML model and are not rewritten into an external (text-based) requirements repository. As often as possible, SysML model artifacts (e.g. operations, ports, states) are used directly as “requirements”, and their description fields are written in the same way as requirements. Only non-functional system requirements are modeled as SysML requirements (excluding system-specific functional requirements from stakeholder input), and these non-functional requirements are combined with existing model artifacts (e.g. tasks, ports, states, or system blocks themselves). It’s about the constraints involved (including performance goals). Therefore, two types of “traceability” links can be identified:

One. Implicit traceability: When a strong dependency exists between two model artifacts (e.g. a task belonging to a system block, a port belonging to a system block)

2. Explicit traceability: A satisfaction relationship is declared between model artifacts (e.g. tasks, ports, states, system blocks) and non-functional requirements at the same level, or a refinement relationship is established between system-level requirements and user-level requirements. when declared

During the requirements analysis process, implicit traceability links were created and system blocks were automatically populated with all the operations and ports declared in the various diagrams. Additionally, tasks are also linked to a defined sequence diagram and the state that calls that task. Explicit traceability links must be declared to ensure that all user-level requirements are covered by system-level requirements (inductive relationships) and that all system-level requirements are covered by model artifacts at the same level (satisfaction relationships).

These relationships are declared directly in the requirements diagram or object database. Justifications related to coverage or refinement are recorded as comments within the description field of the requirements diagram. Traceability analysis is performed to verify the completeness of the model and uses requirements tables and traceability matrices, which are specific features of the Artisan Studio tool.

2-5. System Requirements Document

The final step is to automatically generate a document that creates a synthesis of all modeling activities performed during the requirements analysis phase. This document is named “System Requirements Document” (SyRD).

Document creation process:

• Automatically generated: Uses modeling tools to automatically generate documents by synthesizing all relevant data and activities.
• Purpose of Document: This document serves to clearly demonstrate to the project team, stakeholders, and other partners involved how the functional and non-functional requirements of the system were reflected in the modeling process.
• Usability: SyRD is used as a reference document during the design and development phase of a project, acting as a basis for verifying that the system is being designed and implemented to meet defined requirements.

This document comprehensively organizes all essential information and requirements collected and analyzed during the requirements analysis phase of the project, helping the project team proceed with clear guidance and direction.

---

3. Architecture design phase

The purpose of the architecture design phase is to describe how the system will be structured internally to perform its expected functions. Within the SysCARS-CS simplified workflow presented here, the physical architecture is developed directly taking into account the implementation technology. Logical architecture design activities are limited to identifying internal functionality; there is no intermediate logical architecture.

Main steps:

1. Identify the set of internal functions that a system element (or component) must provide
2. Describe how these internal functions are activated depending on system state
3. Define a physical architecture capable of performing the required internal functions
4. Consistently assign internal functions to physical components
5. Develop and detail the physical interfaces and interactions of components
6. Develop and detail relevant component requirements
7. Assess the effectiveness of physical architecture

At this stage, all analyzes are performed from an internal perspective and the system is considered a ‘white box’. The developed modeling elements are included in a “System Design Document” (SyDD), which creates a synthesis of all logical and physical architecture design activities. The output of this phase is also a set of “component requirements documents” (CNDs) that contain specifications for the components (or system elements) to be implemented.

This process provides a systematic understanding of how each component of the system is interconnected and integrated to perform its overall function, and supports efficient and effective system design and implementation.

3-1. Internal Functional Identification (ACT)

The purpose of this step is to provide detailed information about the internal behavior of tasks belonging to a system block. This performs a similar task to traditional internal functional analysis. For this analysis, each task is accompanied by a top-level activity diagram, which describes how its key functions are implemented by internal technical functions. These descriptions may include several layers of activity diagrams.

Structure of an activity diagram:

• Representation of data flow and control flow: Activity diagrams use data flow and control flow to organize the internal activities to be performed through hierarchical decomposition.
• Lowest-level activities in the hierarchy: The lowest-level activities (i.e., leaf activities) in this hierarchy represent calls to basic operations (call-operation-actions) that model the internal functionality.

Terminating rules for hierarchical decomposition:

• Each identified primary task must be assignable to a unique system element (or component) in the physical architecture. This is the rule that concludes the decomposition process.

Important points related to running the system model:

• A high-level activity diagram that describes the internal behavior triggered by the system state machine. This makes it an interesting and essential property for subsequent execution of the system model.

This approach clearly defines how each internal function of the system is implemented and interconnected, contributing to improving overall system design and efficiency. Additionally, through integration with system state machines, you can accurately simulate the dynamic behavior of how the system should react in various situations.

3-2. Physical Architecture Definition (BDD)

The focus of the physical architecture design phase is on assigning basic tasks to the components (or parts) of the physical architecture structure. This structure may come from previous trade-off analysis studies, or it may be an existing architecture derived from long-term experience with the product line. This is why the specification of an intermediate logical architecture independent of technology choice is largely unnecessary.

Split criteria for allocation:

• The partitioning criteria used to allocate internal functionality to components minimizes the impact of requirements and technology changes and addresses key issues such as performance, reliability, efficient reuse of commercial off-the-shelf products (COTS), maintainability, security, and cost. It must be dealt with effectively.

Approach at model level:

• At the model level, for each component (or part) of the physical architecture, an internal physical block is declared, which owns the basic operations assigned to it.
• In order to keep track of the analyzes previously performed at the system level, it was decided to define the higher-level physical (system) blocks that will be used subsequently as specializations of the system blocks studied in the previous phase (i.e. the requirements analysis phase).
• Block definition diagrams are used to describe the physical architecture, i.e. the configuration relationships between higher-level physical (system) blocks and their constituent physical blocks.

This approach clearly defines how each component of the architecture interconnects and integrates to perform its overall function, supporting efficient and effective system design and implementation. A clear definition of the physical architecture plays an important role in optimizing the overall performance and maintainability of the system.

3-3. Physical Internal Interface Identification (IBD)

The purpose of this step is to provide detailed information about the interaction flow between internal physical blocks, for which we use internal block diagrams. Physical interfaces between internal physical blocks are represented through ports, which can be directly connected to other internal physical blocks or to external interfaces of higher-level physical (system) blocks. Interface identification procedure:

1. Specify the type of data flow: Each port must have a SysML item type or flow specification associated with it to specify the type of data flow allowed.
2. Avoiding diagram information overload: To avoid information overload in one diagram, and to facilitate communication with specific teams, multiple internal block diagrams will be described.
3. Diagrams by interface type: Each diagram corresponds to a specific type of interface (e.g. mechanical, electrical, data processing bus, etc.).

This approach clearly defines how each component of the system is interconnected and integrated, and helps you effectively manage and communicate the technical details of each interface. It plays a key role in the design and integration of the physical architecture and contributes to optimizing the overall performance and reliability of the system.

3-4. Internal Scenario Definition (SD)

The internal scenario definition step may involve establishing a white box sequence diagram that focuses on the collaboration between the various internal components, to address the physical components that require significant granularity to address domain-specific considerations. This activity is distinct from black box sequence diagramming, which focuses on identifying key features at the system level and is implemented only for particularly important scenarios.

Features of the activity:

1. White Box Internal Scenario: By exposing the internal physical blocks in the same sequence diagram, sequential activation of basic functions (operations) owned by system blocks is expected at the system level. Make sure it’s consistent with what you’ve done.
2. Importance of state-based behavior: Physical internal components with significant state-based behavior may include state machines as part of their specifications.

What a sequence diagram does:

• Highlight Interactions: White box sequence diagrams detail how internal components interact and communicate. This is important to clearly see the flow of data and control between components and ensure the overall functionality of the system.
• Detailed analysis of critical scenarios: This analysis is performed only for particularly important or complex scenarios, allowing you to focus your resources on critical parts of your project.

These approaches play a critical role in optimizing system performance and reliability and are essential for understanding the interactions between individual components of complex systems. Additionally, by systematically addressing the state-based behavior of components, you can improve the responsiveness and efficiency of your system.

3-5. Physical Architecture Traceability Verification (REQ)

The process of verifying the traceability of the physical architecture is done in the same way as was done in the requirements analysis phase, and the same applies to the requirements related to the internal physical blocks. Considerations about implicit and explicit traceability links are also valid here.

Traceability verification process:

1. Implicit Traceability Links: Created during the architecture design process, internal physical blocks are automatically populated with all default operations and ports declared in various diagrams. Additionally, primary operations are indirectly linked to the state and activity diagrams that call them.
2. Explicit traceability links: Ensures that all system-level requirements are satisfied by component-level requirements (induced relationships), and that all component-level requirements are satisfied by model artifacts at the same level. (satisfactory relationship) must be declared. These relationships are declared directly in the requirements diagram or object database.

Verification of model completeness:

• Traceability analysis is performed to verify the completeness of the model, using requirements tables and traceability matrices. This is a specific feature of the Artisan Studio tool.

Uses of engineering analysis results:

• The results of engineering analysis of the physical architecture are capitalized within the model. This information is often referred to as Measures of Effectiveness (MoEs) and is incorporated as a value attribute into the high-level physics block that describes the physical architecture. Estimates of MoEs come from specific analyzes performed using appropriate tools such as modeling and simulation environments. These analyzes cover a variety of analysis objectives, including performance, robustness, safety, and cost.

This process clearly defines how each component of the physical architecture is interconnected and integrated to meet overall system requirements, and plays a critical role in optimizing the overall performance and efficiency of the system.

3-6. System design document and component requirements document

The final step is to automatically generate a document that creates a synthesis of all modeling activities performed during the architecture design phase. This document is named “System Design Document” (SyDD).

Create a System Design Document (SyDD):

• Purpose: To document the overall design of the system by synthesizing all activities during the architecture design phase.
• Auto-Generate: Use modeling tools to automatically generate documents by synthesizing relevant data and activities.

A physical architecture model results in a specification of the components to be implemented in each specific discipline (e.g. hardware, software, machines, etc.). A specification document is required for each internal physical block within the physical architecture to isolate the relevant information needed by the team developing each component. These documents are called “Component Requirements Documents” (CND) and are generated automatically, extracting all artifacts attached to the internal physical block under consideration and filtering out confidential or unnecessary information.

Create a Component Requirements Document (CND):

• Automatically generated: Automatically generates documents containing specific specifications for each internal physical block, allowing each team to effectively use the information needed for development.
• Purpose: Provide specific needs and design details for each component, allowing each team to work with clear guidance.

These documents promote effective communication and collaboration between the various disciplines of the project and play a critical role in the development and integration of each component. This helps ensure effective design and implementation of the entire system.

---

In this post, we only cover the procedural aspects described in the paper ‘MBSE Method in SysCARS’. However, this paper explains in detail how MBSE using SysML is applied to mechatronic automotive embedded systems and the know-how, constraints, and difficulties that arise in the process. However, since this paper was published in 2014, there may be some differences from the current situation.

If you are interested in this topic, I recommend you find and read this paper. In particular, it will provide a lot of insight to those who want to introduce MBSE using SysML for the first time in the field.

---

If you are interested in other articles about the MBSE Methods, please refer to the links below!

[MBSE-Method] #1. OOSEM (Object-Oriented Systems Engineering Methodology)

[MBSE-Method] #2. MBSE Grid