SEBoK (Guide to the Systems Engineering Body of Knowledge)

https://sebokwiki.org/wiki/
Admin
SEBoK is a comprehensive guide to systems engineering knowledge that covers the full lifecycle of...
Tokens:69,145
Snippets:49
Trust Score:9.8
Update:1 year ago
Show doc for...
Tokens:
Raw
### SysML State Machine Diagram Example

Source: https://sebokwiki.org/wiki/Functional_Architecture

Showcases an example SysML State Machine Diagram for an automotive system, illustrating the different states and transitions the system can undergo.

```SysML
/**
 * Figure 5. Example SysML State Machine Diagram for an Automotive System.
 * (SEBoK Original)
 */
// Diagram representation would be here if it were actual code.

```

--------------------------------

### Software Construction: Low-code/Zero-code Platforms

Source: https://sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide

This snippet describes the inclusion of low-code/zero-code (no-code) platforms within the Software Construction knowledge area. These platforms represent modern construction techniques and practices that facilitate faster development cycles.

```text
low-code/zero-code (i.e., called no code) platforms
```

--------------------------------

### SysML Activity Diagram Example

Source: https://sebokwiki.org/wiki/Functional_Architecture

Provides an example SysML Activity Diagram for the specific function 'Control Vehicle Acceleration' in an automotive system, detailing the process flow.

```SysML
/**
 * Figure 4. Example SysML Activity Diagram for the Function “Control Vehicle Acceleration” in an Automotive System.
 * (SEBoK Original)
 */
// Diagram representation would be here if it were actual code.

```

--------------------------------

### SysML Use Case Diagram Example

Source: https://sebokwiki.org/wiki/Functional_Architecture

Illustrates a SysML Use Case Diagram for an automotive system, representing the functional architecture through user interactions and system functions.

```SysML
/**
 * Figure 2. Example SysML Use Case Diagram for an Automotive System.
 * (SEBoK Original)
 */
// Diagram representation would be here if it were actual code.

```

--------------------------------

### Executable Systems Engineering Method (ESEM) for SysML

Source: https://sebokwiki.org/wiki/Applying_a_Model-Based_Approach_to_Support_Requirements_Analysis_on_the_Thirty-Meter_Telescope

ESEM augments OOSEM by enabling executable models using SysML diagrams for enhanced requirement verification and analysis. It facilitates integration of supplier/customer models and uses state machines, activity diagrams, and ports for modeling component behavior and communication.

```SysML
// ESEM augments OOSEM by enabling executable models that enhance understanding, precision, and verification of requirements through applying analysis patterns specified with various SysML diagrams.
// ESEM also enables integration of supplier/customer models.

// Conceptual model specifies technology-independent system components and captures their behavior.
// Component behavior is captured using state machines and activity diagrams, and constraint parameters are captured in a table.
// Communication across internal and external system components is accomplished through the sending and receiving of signals through ports.

// Realization model imposes technology-dependent constraints on the design solutions.
```

--------------------------------

### Incremental-build: Iterative Implementation-Verification Cycles

Source: https://sebokwiki.org/wiki/Incremental_Life_Cycle_Model

The Incremental-build model focuses on iterative cycles of implementation, verification, validation, and demonstration. Each increment builds upon the previous one, allowing for phased delivery and testing of system components.

```text
Incremental-build | Iterative implementation-verification-validations-demonstration cycles
```

--------------------------------

### SysML Block Definition Diagram Example

Source: https://sebokwiki.org/wiki/Functional_Architecture

Presents an example SysML Block Definition Diagram that shows the hierarchical representation of functions within an automotive system's architecture.

```SysML
/**
 * Figure 3. Example SysML Block Definition Diagram Representation of Hierarchical Functions for an Automotive System.
 * (SEBoK Original)
 */
// Diagram representation would be here if it were actual code.

```

--------------------------------

### Interface Modeling Method using SysML

Source: https://sebokwiki.org/wiki/Architecting_Approaches_for_Systems_of_Systems

Illustrates leveraging interfaces in SoS architecting and assembly using SysML. This method defines standards for interface modeling, employing a black-box/white-box approach to specify interface compliance.

```SysML
SysML defining the Interface Modelling Method that employs a black-box / white-box approach and the final step of which is to specify the standards that define interface compliance.
```

--------------------------------

### Therac-25 Software Development (PDP-11 Assembly)

Source: https://sebokwiki.org/wiki/Medical_Radiation

The Therac-25 software was developed by a single individual using PDP-11 assembly language. This snippet represents the programming language used, though no specific code examples are provided in the text.

```PDP-11 Assembly
/* The Therac-25 software was developed using PDP-11 assembly language. */
/* No specific code examples were provided in the source text. */
```

--------------------------------

### LDSE Design Techniques Overview

Source: https://sebokwiki.org/wiki/A_Framework_for_Viewing_Quality_Attributes_from_the_Lens_of_Loss

This section details the core principles of Loss Control Design Techniques for Secure Engineering (LDSE) as proposed by Winstead (2021). These principles are intended to guide the design of cyber-physical systems to minimize loss and enhance security.

```English
Anomaly Detection: Any salient anomaly in the system or in its environment is detected in a timely manner that enables effective response action.
Commensurate Protection: The strength and type of protection provided to an element must be commensurate with the most significant adverse effect that results from a failure of that element.
Commensurate Response: The design should match the aggressiveness of an engineered response action’s effect to the needed immediacy to control the effects of each loss scenario.
Continuous Protection: The protection provided for an element must be effective and uninterrupted during the time that the protection is required.
Defense-in-depth: Loss is prevented or minimized by employing multiple coordinated techniques and strategies.
Distributed Privilege: Multiple authorized entities must act in a coordinated manner before an operation on the system is allowed to occur.
Diversity (Dynamicity): The design delivers the required capability through structural, behavioral, data, or control flow variation.
Domain Separation: Domains with distinctly different protection needs should be physically or logically separated.
Least Functionality: Each element should have the capability to accomplish its required functions, but no more.
Least Persistence: System elements and other resources should be available, accessible, and able to fulfill their design intent only for the time they are needed.
Least Privilege: Each element should be allocated privileges that are necessary to accomplish its specified functions, but no more.
Least Sharing: System resources should be shared among system elements only when necessary, and among as few system elements as possible.
Loss Margins: The system is designed to operate in a state space sufficiently distanced below the threshold at which loss occurs.
Mediated Access: All access to and operations on system elements are mediated.
Protective Defaults: The default configuration of the system provides maximum protection effectiveness.
Protective Failure: A failure of a system element should neither result in an unacceptable loss, nor invoke another loss scenario.
Protective Recovery: The recovery of a system element should not result in, nor lead to, unacceptable loss.
Redundancy: The design delivers the required capability by the replication of functions or elements.
```

--------------------------------

### Goal-Question-Metric (GQM) Paradigm for Measurement

Source: https://sebokwiki.org/wiki/Assessing_Systems_Engineering_Performance_of_Business_and_Enterprises

The 'goal, question, metric' paradigm is used to guide data collection for specific purposes. Measurement data is collected to answer questions that help achieve defined goals, such as cost reduction or value increase.

```English
The "goal, question, metric" paradigm (Basili 1992) should be applied, in which measurement data is collected to answer specific questions, the answer to which helps achieve a goal, such as decreasing the cost of creating a system architecture or increasing the value of a system to a particular stakeholder.
```
Tokens:
Raw