System engineers are heavy users of modeling and design languages such as SysML. These design languages enable them to design, refine, verify, and test systems early in development. On the other hand, and especially with the emergence of agile methodologies, design and development activities in software engineering are intermingled and performed in iterations. Modern systems, however, exhibit increasing interdependence between software and physical components. Hence, there is a growing need to develop design languages that can bridge the gap between system and software engineering communities. This paper proposes fSysML, a foundational and executable subset of SysML geared towards facilitating the development of modern Cyber-Physical Systems. fSysML defines both a surface syntax for a SysML subset, and an executable semantics that is directly mapped to a modern object-oriented language. fSysML is demonstrated by the development of a self-adaptive system from the healthcare domain.
Cyber-Physical Systems (CPS) are integrations of computation, networking, and
physical processes [
Software and hardware components are typically developed following different development processes and methodologies. One key distinction is propensity to change. In the software world, change is embraced and can influence many aspects of development. While in the physical world, it is costly and cannot be accommodated without significant cost.
As a result, software and systems engineers have different perspectives regarding design and development activities. System engineers adopt modeling and design whole-heartedly, and do not typically require modeling languages to be executable. In fact, execution for a systems engineer often refers to execution of a simulation or model-based testing. System engineers rely on precise and elaborate models to test and verify systems before the commencement of development activity. Moreover, design models are the gold standard against which any development artifact needs to be tested.
Software engineers, on the other hand, utilize more integrated approaches and work iteratively and incrementally. Modern agile software development processes encourage the delivery of an executable artifact at every iteration. These partially complete software systems are used to discover additional requirements, and feed into planning, scheduling and staffing management.
With the emergence of CPSs, there is an emerging need for platform and design languages that can accommodate both system and software development processes. In this paper, we address this emerging need by introducing fSysML; foundational SysML for CPSs. fSysML defines a textual surface language for a subset of SysML and integrates this subset with an executable subset of UML. The result is a language that can define many aspects of CPS properties, including Blocks, Requirements, Goals, Users, Use Cases, as well as behavioral and compositional aspects. We demonstrate fSysML using the design of a self-adaptive system from the healthcare domain. Self-adaptive systems demonstrate further interdependencies between both software and physical components, making it ideal for the demonstration of fSysML.
This paper is organized as follows. We introduce the motivation and significance of this research in Section 2. A background on self-adaptive systems, system modeling and MDE is introduced in Section 3. Section 4 introduces a running example followed by detailed explanation of fSysML in Section 5. The language grammar and related work are covered in Section 6 and 7 respectively. Finally, we conclude with a discussion of future work and conclusion. 2
The authors of this paper are actively collaborating with a national aerospace agency and are investigating a roadmap for adoption of Model Driven Engineering (MDE) paradigm. From early stages of the investigation, the researchers observed a significant discrepancy between system and software engineers. The bulk of the development effort in the system engineering side is closely related to development of various types of design models. Key approvals, certifications, and testing are performed against system models. Software is treated as a black-box component with elaborate behavioral specification. The software engineers use design models sparingly and typically target development of an executable artifact.
Systems engineers reported on their need for a textual syntax, equivalent to the visual representation, of their SysML models. The rationale is that text can be versioned and merged more effectively along with the software artifacts. Furthermore, it maybe easier to manipulate and layout textual artifacts than visual models, particularly as models become large and complex. More importantly, such a textual language will facilitate collaboration and integration between system and software engineers. This observation has motivated the research presented in this paper; namely, the development of a textual SysML language that can enable effective collaboration between both software and system engineers. 2.1
There is a recognized conflict between MDE and agile methodologies [
There is significant evidence that software engineers do not in fact adopt UML and
modeling as much as desired [
In this section, we introduce background on system and software modeling, and selfAdaptive systems. 3.1
The Object Management Group (OMG) has adopted a vision where models become the key development artifacts, from which executable elements can be generated. The premise includes improved productivity and quality of software systems. UML has emerged as the de facto modeling notation in software engineering and has been well evaluated academically.
Since UML is a general-purpose modeling notation, not all of its elements have
well-defined execution semantics. This has resulted in numerous challenges for the
development of precise models. As a result, OMG has defined a subset of UML with
defined semantics called Foundational UML (fUML) [
The landscape of system modeling is more complex. System engineers use a wider variety of modeling notations and design languages. System designs are used not only to test and verify the system, but also to derive the cost and schedule associated with its development. In this paper, we use SysML as the representative system design language, but the approach proposed in this paper can be applicable beyond SysML.
SysML borrows many notations from UML; this includes use case modeling, structural modeling, and behavioral modeling using a variant of UML state machines. SysML adds additional design notation to model requirements, blocks and components, and system parameters. 3.3
Self–adaptive systems have the unique property of dynamically adapting to changes
in environment, operating context, or changes in system goals or priorities [
Self-adaptation is realized by identifying and implementing a number of adaptation strategies or tactics. Tactics application is performed in response to an external change in the operating environment or deterioration in system performance, and aims at improving one or more of the system’s goals. Take for example a web server that is supposed to service user requests. The system’s goals may include speedy responses, and to keep the number of time-out requests to a minimum. At peak hours when performance declines, the web-server may apply a performance tactic such as load sharing with a back-up server. 4
To demonstrate fSysML, we use a self-adaptive monitoring system from the healthcare domain. The monitoring system reports on patients key vital signs in real time and notifies specific caregivers when certain conditions are present. The overall goal of the system is to speed patient discharge from the Heart Unit and reduce perpatient costs; while at the same time maintaining a low re-admission rate and high patient satisfactions (Appendix – Goal Model).
Amongst the monitored vital signs, the heart rate and oxygen level are measured by embedded sensors. These sensors produce a continuous stream of data. The system analyzes the data on the fly and stores data points only when certain rules succeed. The system behavior is driven in part by readings from these sensors (Appendix 1– Behavior Model). The next section elaborates on this example further by highlighting key language elements.
fSysML Overview fSysML targets system and software engineers in an integrated manner. As such, it supports system and software modeling with little or no distinction. In the following sections we will illustrate the language elements focusing on system modeling. 5.1
The language supports the definition of key system goals. A goal can be measured by physical elements (such as a sensor) or by a combination of elements that can be quantified by a Key Performance Indicator (KPI). Goals can be broken down into sub-goals. In this case, two goals can both contribute to a higher-level goal through an “AND” or an “OR” contribution. “And” contribution means the lower satisfaction of the sub-goals is transferred to the super goal, while OR contribution means the higher satisfaction is transferred to the super goal. Contributions may also be associated with a weight. Listing 1 is an fSysML snippet that describes the system goals. A visual depiction of System Goal is illustrated in the Appendix 1.
goal Discharged { contributesTo PatientSatisfaction{0.7}; stakeholder Patient, Physician; } goal NormalHeartRate { contributesTo Discharge{0.5}; stakeholder Patient, Physician; KPI heartRateMeasurement threshold = 50; failureLimit = 0; correctiveAction = heartRateTreatment; } goal NormalBloodOxygenLevel { contributesTo Discharge{0.5}; stakeholder Patient, Physician; KPI bloodOxygenMeasurement threshold = 25; failureLimit = 0; correctiveAction = oxygenTreatment; } goal LowCost { contributesTo PatientSatisfaction{0.3}; stakeholder Patient, Physician; } softGoal PatientSatisfaction { stakeholder Patient, Physician; decompositionType = 'and'; }
Listing 1. System Goals and Goal Compositions 5.2
Not all system goals need to succeed at all times. For example, if an oxygensupplying system is not connected to a patient, then oxygen concentration levels need not be above a threshold. Some goals can fail sometimes without repercussions, and some goals cannot fail at all. This is defined by modeling the failure limit. A failure limit of one means that if a goal fails once, an adaptive action must be taken (adaptive actions are discussed later). Similarly, a failure limit of two means that a goal can fail twice over a specified period of time without repercussions (i.e, associated adaptive action will be applied after the second goal failure occurrence). A failure limit of zero means that a specific goal should not be allowed to fail at all. In such a case, the system must apply rules to take precautionary actions if the goal trends towards failure. 5.3
A goal failure, even if permitted, may or may not trigger an adaptive action. An adaptive action is defined by a set of instructions (or tactics) with the aim of eliminating or reducing the reoccurrence of goal failure. The effectiveness of a particular adaptive action is measured by 1) the satisfaction of the goal immediately connected to the adaptive action element and 2) the top-level system goal satisfaction. Adaptive actions are defined algorithmically using ALF. 5.4
A scenario or a process is a sequence of tasks that can take place in a defined sequence. The sequence can be dependent on conditions or actions that can occur at run time. fSysML supports the definition of scenarios, join and fork control flows. As shown in the following example (Listing 2), the scenario Triage contributes to the goal Discharge. In this scenario, if a treatment is required, then the path along the treatment task is taken. Otherwise, the path along discharge task is taken. task Treat { form DischargeForm { actor Physician; date mandatory; dependsOn TreatmentForm; } time optional; Patient.firstName mandatory; task Discharge { Patient.lastName mandatory; actor Physician; Physician.firstName mandatory; dependsOn DischargeForm; } Physician.lastName mandatory; .. } task OxygenTreatment {
actor Physician; } task HeartRateTreatment { actor Physician; form TreatementForm; } scenario Triage { satisfies Discharged; [needsTreatment]? {Treat}:{Discharge}; } form TreatmentForm { date mandatory; time mandatory; Patient.firstName mandatory; Patient.lastName mandatory; Patient.diagnosis mandatory; Patient.diagnosisCode mandatory; Physician.firstName mandatory; Physician.lastName mandatory;
Physician.employeeID mandatory;}
Listing 2. Tasks and Scenarios 5.5
fSysML defines a textual syntax for UML state machines to define system behavior. The state machine subset supported by fSysML includes states, events, guards, transitions, actions, entry, do, and exit activities.
At the top level of the state machine in Listing 3, the system is functioning under one of two states, Normal and Abnormal. In both states, the streams of sensor data is received and analyzed. If data streams show abnormalities, the system continues to monitor but is now functioning under the abnormal state. While in the Abnormal state, the system may itself trigger some corrective actions to try to remedy the deficiencies. If successful, the system may return to the Normal state. These behavioral elements specify the behavior of some system components or Blocks (discussed in the next subsection). In this example, we illustrate the behavioral modeling for the monitor control unit.
The state machine syntax is an extension of Umple’s state machine modeling
syntax [
// From BDD : block ControlUnit { .. ..
block HR_Sensor { // behavioral definition state Normal { region HR_Sensing {
NormalRate { entry/{ updateDisplay();} do{monitor_HR();
analyze_HR_Rule();} Abnormal_HR_Detected->Abnormal_HR;} } region Dormant { .. } } state Abnormal { .. } } }
Listing 3. Behavioral Model block HR_Sensor { parts: protective_housing, mount_assembly, sensor_module, electronics_assembly, display values: dimension: Size power: Width field_of_sensing: int orientation: int flow_ports: in_ligh_in: Light sensor_IO: Sensor_interface standard_ports: control: Sensor_signal }
Listing 4. Block Definition 5.6
Block Definition Diagrams (BDD) are an important part of system modeling [
A block has four groups of properties; namely, parts, values, flow ports and standard ports. The Block Definition Diagram (BDD) describes composition relationships denoted by --- (Listing 5). For example, HR_Sensor is composed of three External Wirings, one enclosure and one battery. The syntax for blocks and block definitions is different than the rest of fSysML syntax. For example, dimension is of type size. One would expect that the type would precede the name of the attribute such as follows: values { size dimension; }
This choice of syntax may in fact look unusual for a software engineer. This choice in fSysML was influenced by 1) SysML visual diagrams, and 2) system engineers’ preferences. 5.7
fSysML defines users of the systems, and user groups that can share a common characteristics, such as access privilege. A specific instance of a user is referred to as an Actor. Users, Actors and User Groups can participate in a scenario, and may be assigned to tasks. Users and Actors need not be a human actor, but can be any other subsystem or a block.
bdd MonitoringComponent { actor Patient { bdd HR_Sensor { int patientID; 1 --- 3 External_Wiring; string firstName; 1 --- 1 Enclosure; string lastName; 1 --- 1 Battery; } int diagnosisCode; } bdd Oxygen_Sensor { .. } .. actor CareProvider; { .. int current_heart_rate; bdd Enclosure { int target_heart_rate; 1 --- 1 front_housing; int current_blood_oxygen; 1 --- 1 back_housing; int target_blood_oxygen; } 1 --- 2 secure_strap; .. actor Physician { .. int employeeID; } } .. }
Listing 5. Block Definition Modeling Listing 6. System Actors 6
fSysML is developed using Xtext [
The language supports tagging model elements. Tagged values appear between curly brackets and may have typed data elements. Tagging is useful when engineers want to analyze a subset of the system elements. For example, a subset of system elements may be selected for regression testing, or for measuring overhead costs. A Soft Goal is similar to a Goal, except that a Soft Goal typically refers to a nonfunctional aspect of the system. Nevertheless, a Soft Goal may still be quantified using a KPI. A scenario may itself contain other scenarios. fSysML treats a task as a unitary action that cannot be further broken down.
fSysML: elements+=(Actor|Usergroup|KPI|Goal|Softgoal|stateMachine|Block|BDD)*; Contribution: contributesTo' (goals += [Goal]|goals += [Softgoal])'{'weight = INT'};'; TaggedValue: 'taggedValue' '=' '{'(ID '=' Datatype',')*(ID '=' Datatype)'}'; KPI: 'KPI' name=ID'{'(TaggedValue)?(goals_contributed_to +=Contribution)*'};'; Goal: 'Goal' name = ID '{'(TaggedValue)? (goals_contributed_to += Contribution)* ('Stakeholder' actors += [Actor]';')+ (('KPI' indicators += [KPI]';')* | ('SoftGoal' softgoals += [Softgoal]';')*)('decompositionType' '=' dType=DecompositionType';')? '};' ;
Softgoal: 'SoftGoal' name = ID '{'(TaggedValue)? (goals_contributed_to += Contribution)+ ('Stakeholder' actors += [Actor]';')+ (('KPI' indicators += [KPI]';')* | ('SoftGoal' softgoals += [Softgoal]';')*) '};';
Task: 'Task' name = ID '{'(TaggedValue)? 'Actor' actor += [Actor]';' ('Form' forms += [Form]';')* '}' ;
Scenario: 'Scenario' name = ID '{'('satisfy' satisfied_goals += [Goal])+('depends' dependent_forms += [Form])+ (tasks += [Task]'->')+ ('['boolean'], {'ss_one+=SubScenario'},{'ss_two+=SubScenario'}'|(tasks += [Task]';') ; SubScenario: (tasks += [Task]'->')+ ('['boolean'],{'ss_one+=SubScenario'}, {'ss_two+=SubScenario'}'|(tasks += [Task]';') ;
Listing 7. Part of fSysML Grammar 7
There has been numerous and growing trend in supporting textual UML modeling.
Such approaches have materialized in a number of tools. textUML supports a library
and an API for creating UML diagrams using Java syntax [
fSysML extents the standard SysML language with goal modeling. This is used to
help assess adaptive actions effectiveness. Laleau et al [
Manzoor [
Cyber-Physical Systems exhibit greater interplay between both physical elements and software elements, with significant feedback loops and shared controls. Development of such systems requires both software and system engineers to collaborate. Where modern software engineers follow an iterative and incremental processes, system engineers adopt disciplined design-oriented processes.
To facilitate the development of Cyber-Physical Systems, we propose a design language that encompass the following key properties. 1) Enables the design and modeling of both physical and software elements. This is achieved by defining a subset of SysML and specifying a surface textual syntax for that subset. The result is integrated with a textual syntax for modeling of software elements. 2) Eliminates to the greatest extent possible the distinction between physical and software elements. This is achieved by defining a uniform language for both types of elements. 8.1
Parametric modeling definition in the language is ongoing. Parametric modeling
for systems supports trade-off analysis, model based testing, and typically supports
the definition and execution of system level constraints. We are investigating the use
of a language such as OCL [
CBS function in an environment exhibiting continuous properties with many sources of uncertainties. How to effectively model risks and uncertainties and present it as integral elements in the language is yet to be investigated. Effective modeling of these elements contributes to addressing key state-of-the-art research challenges, including 1) model testing of cyber-physical systems under uncertainties [32], 2) model based analytics of CBS [33], among others.
System requirements is another area of ongoing investigations. In SysML, requirements are defined in a hierarchical fashion. A requirement may have attributes such as an ID and text, and may be related to one or more modeling elements. To implement this in fSysML, we must introduce new concepts, such as satisfies (or isSatisfiedBy), contributesTo (or contributedToBy), and realize (or realizedBy). These concepts will relate requirement elements to various system and software model elements. Semantics of such concepts must have implications to testing and analysis activities. For example, a change of a model element should be reflected to all related elements in requirements. Unit testing should cover all requirements contribute to relationships and other modeling elements. 30. Whittle, Jon, et al. "RELAX: a language to address uncertainty in self-adaptive systems requirement." Requirements Engineering 15.2 (2010): 177-196. 31. Derler, Patricia, Edward A. Lee, and Alberto Sangiovanni Vincentelli. "Modeling cyber– physical systems." Proceedings of the IEEE 100.1 (2012): 13-28. 32. Briand, Lionel, Shiva Nejati, Mehrdad Sabetzadeh, and Domenico Bianculli. "Testing the untestable: model testing of complex software-intensive systems." In Proceedings of the 38th International Conference on Software Engineering Companion, pp. 789-792. ACM, 2016. 33. Sharma, Abhishek B., Franjo Ivančić, Alexandru Niculescu-Mizil, Haifeng Chen, and Guofei Jiang. "Modeling and analytics for cyber-physical systems in the age of big data." ACM SIGMETRICS Performance Evaluation Review 41, no. 4 (2014): 74-77.
Appendix 1: Behavioral Model