Introducing the Main Structural Capabilities of SysML
The SysML standard gives systems engineers and architects a much-needed way to collaborate using a common language that is specifically designed to support this process. As a standard modelling language for systems engineering, SysML enables improved communications across development teams, while greatly enhancing the ability to manage ever-growing system complexity. Further, by enabling an electronic representation of the product design, SysML opens the door to analytics for faster and more effective decision-making across the entire systems development lifecycle.
SysML Example
Let’s explore the main structural capabilities of SysML through an example: a Rain Sensing Wiper (RSW) system. This example is inspired by a real-life product which experienced some challenges during its initial development. This example serves to illustrate the importance of understanding a product at the level of its subsystems in order to prevent complex failure modes leading to costly product recalls. In this case, the RSW manufacturer endured a lengthy root-cause analysis that eventually required a design change. The example used in this article presents a model that is resilient to the failure the manufacturer experienced.
The goal of the RSW is to wipe the surface of the windshield automatically whenever droplets of liquid are detected on the windshield’s exterior surface. In addition, the amount of liquid detected dictates the speed of the wiper. This system has three main components:
- the software that controls the behaviour of the wiper
- an electronic control unit that executes the software
- a sensor fixed on the windshield’s interior surface whose task is to sense droplets through the windshield.
The detailed model presented below describes many aspects of the RSW system. This example constitutes a realistic product in the area of embedded electronics for the automotive industry whose design greatly benefits from a SysML representation.
The Context Diagram
When modelling a system, an important primary task is to decide what belongs to the system and what does not. The Context Diagram is an informal way to represent the boundaries of the system.
The Context Diagram establishes the scope of the system. In this instance, it identifies three actors for the system: Maintenance (for repair purposes), Car Electrical System (to activate the system in the car), and Driver (to manually disable the system, for example). Three external systems are considered: the wiper interface, the windshield, and the car electrical system. Note that a user-defined keyword “external” is used to qualify the external components. Furthermore the car electrical system also provides electrical power to the RSW, hence it is considered both an actor and external system.
The Requirements Diagram
Product requirements have traditionally been represented as text, often accompanied by figures and drawings, and stored in files or databases. The requirements describe all the product functions, as well as the constraints under which these functions should be realised. SysML allows the representation of requirements as model elements. Hence, requirements become an integral part of the product architecture. The language offers a flexible means by which to represent text-based requirements of any nature (e.g. functional, non-functional) as well as the relationships between them.
Requirements have a set of default attributes (id and text) and additional attributes can added if required. Sub-requirements are related to their parent requirements using the crosshair relationship. For example, in Figure 2, some of the sub-requirements of Automatic Wiping are connected to it using the crosshair; the parent requirement is a package for the embedded requirements. Another example of a requirement acting as a package for other requirements is Core Functions which contains two sub-requirements.
During requirement analysis (e.g. decomposition and flow-down) new requirements are created by derivation. These new requirements can be connected to the initial ones with the deriveReqt dependency. For example, in Figure 2, a set of core functions for the product are derived from the set of requirements under Automatic Wiping. Another example of a derived requirement is the quality requirement System Calibration which states that the system should be calibrated. This is the requirement added to the product after the RSW failure was identified. The satisfaction of this requirement ensures that the product will be resilient to changes in the sensor and windshield characteristics.
Describing System Structure
SysML provides a basic structural element called a Block whose aim is to provide a discipline-agnostic building block for systems. Blocks can be used to represent all types of system components; e.g. functional, physical, human. Blocks should not be seen as a means to represent a physical entity in particular. They are aimed at representing any type of structure, concrete or abstract. Blocks assemble to form architectures that represent how different elements in the system coexist.
The SysML Block Definition Diagram (BDD) is the simplest way to describe the structure of the system. It is the equivalent to the Class diagram in UML. It is used to represent the system decomposition using, for example, associations and composition relationships. The BDD is ideal for displaying the features of a Block, such as its properties and operations.
Figure 3 shows a BDD for the RSW. For the sake of the diagram’s readability, it does not render the associations between the subsystems and the Rain Sensing Wiper element, although these associations exist in the model. Instead, it uses an illustrative box around each set of components (composite and external) and a black diamond shape over the composite component as visual composition elements. The main components of the RSW are:
- an interface to actuate the wiper
- an electronic control unit
- a sensor
- the windshield element.
Both the interface and the windshield can exist in the car with or without the RSW. Therefore, in SysML, they are so-called reference properties.
The properties and the operations for each Block are visible in Figure 3. Properties are used to model the physical characteristics of the components. The operations (sometimes called services) represent the functional aspects of the system.
Allocating Requirements to Blocks
How can the product structure and the product requirements be related? One of the important consequences of having requirements as model elements is that it allows the designer to specify which components in the system satisfy a given set of requirements. This is called the allocation process. An example of requirements allocation is shown in Figure 4. The left-hand side represents some elements of the RSW while the right-hand side shows a hierarchy of requirements. One way to perform allocation is to use the Satisfy dependency. In Figure 4, for instance, the Rain Sensing Wiper model element is allocated to the requirement named “Automatic Wiping.” Any element in SysML can be used to satisfy a requirement.
The Internal Block Diagram
The SysML Internal Block Diagram (IBD) allows the designer to refine the structural aspect of the model. The IBD is similar to the Composite Structure in UML. In the IBD, properties (or parts) are assembled to define how they collaborate to realise the behaviour of the Block. A part represents the usage of another Block.
The most important aspect of the IBD is that it allows the designer to refine the definition of the interaction between the usages of Blocks by defining ports. Ports are parts available for connection from outside the owning Block. Ports are categorised according to type by the interfaces or Blocks that define what can be exchanged through them. Ports are connected using connectors that represent the use of an association in the IBD.
Two types of ports are available in SysML: Standard Ports handle the requests and invocations of services (i.e. function calls) with other Blocks, and Flow Ports let Blocks exchange flows of information or material. For Standard Ports, an interface class is used to list the services offered by the Block. For Flow Ports, a Flow Specification is created to list the type of data that can flow through the port.
In Figure 5, the initial description of the RSW is refined by showing how parts are interacting inside the Block named Rain Sensing Wiper. The central part of Figure 5 shows the parts of the system that represent the embedded hardware. The parts below are used for mounting the system in the car while the ones above represent the software. A set of standard ports and interfaces are defined to represent the functional aspect of the communication between the parts. For example, the Processing Unit accesses the Actuation interface of the wiper through the interface WiperECUCommunication. The Processing Unit communicates with the RainSensor using a flow port. The data exchanged is two bitstreams, one containing the measurements from the sensor and another containing synchronisation data.
SysML also proposes a rich language to specify the behaviour of the system. Hence all operations on blocks can be described using a behavioural model such as the Interaction diagram, the State Machine diagram and the Activity diagram.
Together, diagrams used to represent structure and behaviour provide a holistic mechanism for system designers to realise the customer’s needs.
Conclusion
SysML is initially aimed at supporting the conceptual stage of the lifecycle of the product, but it supports more generally an integration framework that aims at supporting the entire lifecycle of the product. Creating a formal description of the product at an early lifecycle stage improves the understanding of product requirements and how they answer customer needs. The allocation of requirements to the model elements ensures that these needs are covered and provides a rationale for the engineer in charge of fulfilling these requirements. The rationalisation of the design is therefore a communication tool spanning organisational levels and lifecycle stages. It improves communication across teams, between teams and between teams and decision makers.
The SysML model provides an electronic representation of the product that is leveraged as a decision tool. Trade-off studies may be performed by evaluating functions on the model. At an early stage in the lifecycle, often rough estimations are used; hence the model need not necessarily have a great amount of details in order to be used efficiently. When details are added, or artefacts (for example, subsystem simulations) are produced by detailed engineering work, the model is used to coordinate the various simulations and verify requirements. Thus, the SysML model is an evolving decision tool that is useful throughout the whole lifecycle of the product.