Tutorial presented at the MODELS 2020 virtual conference on the proposed OMG Systems Modeling Language, Version 2, as of the initial submission of the specification.
SysML v2 and the Next Generation of Modeling LanguagesEd Seidewitz
The Systems Modeling Language (SysML) is a particularly successful offshoot of the Unified Modeling Language (UML) tailored for Model-Based Systems Engineering. After a decade of growing use of SysML, in 2017 the Object Management Group (OMG) issued a Request for Proposals (RFP) for a new version of the language. A year into the ongoing work to respond to this RFP, it is clear that SysML v2 needs to be more than just an expansion of the functional capabilities of SysML. Rather, it must address fundamental architectural issues that have made it difficult to further evolve SysML v1 to address the needs of its user community. Therefore, the language is being re-designed using a new kernel metamodel with formally grounded semantics. This kernel can then be extended using semantic model libraries, rather than by expanding the language metamodel itself. This approach will allow SysML v2 to be not only the modeling language for traditional systems engineering, but also the foundation for a whole new generation of modeling languages.
CapellaDays2022 | Saratech | Interface Control Document Generation and Linkag...Obeo
Generation of Interface Control Documents (ICDs) using a model-based method has a number of advantages over text-based approaches. This paper describes the Python-based software that was written to automatically generate different versions of an ICD from a structure model in Capella. One use case for this approach is checking parts changes captured in the Engineering Bill of Materials (EBOM) using a PLM tool. We demonstrate an automated workflow that links changes in the EBOM to a request to vet the change against the ICD. This presentation will discuss our rationale, approach, results, and lessons learned.
Nowadays, we are surrounded by system of systems, autonomous systems, interconnected systems or distributed heterogeneous systems with an increase in architecture complexity.
Keeping these systems operational is a challenge as the number of potential failures which may affect their availability also increases drastically. In order to optimize availability, maintenance activities have to be designed within the design phase of the system.
Whatever the implementation choice, detection, diagnostic or prevention of failures require tests.
The goal for autonomous systems also pushes towards embedded detection and prevention capabilities and thus arguing and decision making between system engineers and maintenance engineers to share solutions in their respective activities.
In this presentation, we talk about the ability of a system designed with Capella to be tested, including in the maintenance phase. This means to interconnect several kinds of models representing different perspectives: System Design (MBSE), RAMS Analysis (Reliability, Availability, Maintainability and Safety) and Testability.
We present how a MBSE approach with Capella can be used to initiate a testability study performed with the eXpress tool from DSI International.
Everyone talks about "data-centricity," but what does that mean in practical terms. It means that you have to have a well defined ontology that can capture the information needed to describe the architecture or system you work with or want to create. An ontology is simply the taxonomy of entity classes (bins of information) and how those classes are related to each other. In this webinar, we will discuss a relatively new ontology, the Lifecycle Modeling Language (LML). LML provides the basis for Innoslate's database schema. In this webinar, we will discuss each entity class and why it was developed. Dr. Steven Dam, who is the Secretary of the LML Steering Committee, will present the details of the language and how it relates to other ontologies/languages, such as the DoDAF MetaModel 2.0 and SysML. He will also discuss the ways to visualize this information to enhance understanding of the information and how to use that information to make decisions about the architecture or system.
STPA Analysis of Automotive Safety Using Arcadia and CapellaDavid Hetherington
This presentation demonstrates the use of the Arcadia methodology and the open source Capella tool to implement a STPA-based analysis technique that augments the conventional HARA, HAZOP. The STPA approach extends the conventional methods to include a holistic perspective considering hardware, software, humans, and control failures in a balanced manner.
Delivered by David Hetherington and Pascal Roques at the ERTS 2022 conference in Toulouse, France on 1 June 2022.
System of Systems modeling comes with a tough decision for practitioners using traditional SysML V1 tools. Do I go with SysML V1, or do I look at Unified Architecture Framework? Capella eliminates that challenge with one notation that can be used for both.
By Tony Komar (Siemens)
Tony Komar has been practicing and supporting systems engineering for over 35 years.
Today he is a key contributor to the development and deployment of model-based system engineering products for Siemens Digital Industries Software.
SysML v2 and the Next Generation of Modeling LanguagesEd Seidewitz
The Systems Modeling Language (SysML) is a particularly successful offshoot of the Unified Modeling Language (UML) tailored for Model-Based Systems Engineering. After a decade of growing use of SysML, in 2017 the Object Management Group (OMG) issued a Request for Proposals (RFP) for a new version of the language. A year into the ongoing work to respond to this RFP, it is clear that SysML v2 needs to be more than just an expansion of the functional capabilities of SysML. Rather, it must address fundamental architectural issues that have made it difficult to further evolve SysML v1 to address the needs of its user community. Therefore, the language is being re-designed using a new kernel metamodel with formally grounded semantics. This kernel can then be extended using semantic model libraries, rather than by expanding the language metamodel itself. This approach will allow SysML v2 to be not only the modeling language for traditional systems engineering, but also the foundation for a whole new generation of modeling languages.
CapellaDays2022 | Saratech | Interface Control Document Generation and Linkag...Obeo
Generation of Interface Control Documents (ICDs) using a model-based method has a number of advantages over text-based approaches. This paper describes the Python-based software that was written to automatically generate different versions of an ICD from a structure model in Capella. One use case for this approach is checking parts changes captured in the Engineering Bill of Materials (EBOM) using a PLM tool. We demonstrate an automated workflow that links changes in the EBOM to a request to vet the change against the ICD. This presentation will discuss our rationale, approach, results, and lessons learned.
Nowadays, we are surrounded by system of systems, autonomous systems, interconnected systems or distributed heterogeneous systems with an increase in architecture complexity.
Keeping these systems operational is a challenge as the number of potential failures which may affect their availability also increases drastically. In order to optimize availability, maintenance activities have to be designed within the design phase of the system.
Whatever the implementation choice, detection, diagnostic or prevention of failures require tests.
The goal for autonomous systems also pushes towards embedded detection and prevention capabilities and thus arguing and decision making between system engineers and maintenance engineers to share solutions in their respective activities.
In this presentation, we talk about the ability of a system designed with Capella to be tested, including in the maintenance phase. This means to interconnect several kinds of models representing different perspectives: System Design (MBSE), RAMS Analysis (Reliability, Availability, Maintainability and Safety) and Testability.
We present how a MBSE approach with Capella can be used to initiate a testability study performed with the eXpress tool from DSI International.
Everyone talks about "data-centricity," but what does that mean in practical terms. It means that you have to have a well defined ontology that can capture the information needed to describe the architecture or system you work with or want to create. An ontology is simply the taxonomy of entity classes (bins of information) and how those classes are related to each other. In this webinar, we will discuss a relatively new ontology, the Lifecycle Modeling Language (LML). LML provides the basis for Innoslate's database schema. In this webinar, we will discuss each entity class and why it was developed. Dr. Steven Dam, who is the Secretary of the LML Steering Committee, will present the details of the language and how it relates to other ontologies/languages, such as the DoDAF MetaModel 2.0 and SysML. He will also discuss the ways to visualize this information to enhance understanding of the information and how to use that information to make decisions about the architecture or system.
STPA Analysis of Automotive Safety Using Arcadia and CapellaDavid Hetherington
This presentation demonstrates the use of the Arcadia methodology and the open source Capella tool to implement a STPA-based analysis technique that augments the conventional HARA, HAZOP. The STPA approach extends the conventional methods to include a holistic perspective considering hardware, software, humans, and control failures in a balanced manner.
Delivered by David Hetherington and Pascal Roques at the ERTS 2022 conference in Toulouse, France on 1 June 2022.
System of Systems modeling comes with a tough decision for practitioners using traditional SysML V1 tools. Do I go with SysML V1, or do I look at Unified Architecture Framework? Capella eliminates that challenge with one notation that can be used for both.
By Tony Komar (Siemens)
Tony Komar has been practicing and supporting systems engineering for over 35 years.
Today he is a key contributor to the development and deployment of model-based system engineering products for Siemens Digital Industries Software.
The openCAESAR project provides an EMF-based implementation of the Ontological Modeling Language (OML), which simplifies the use of semantic web ontologies for modeling and analysis. An OML model can be either be a vocabulary model that defines the terms and rules in a business domain with precise syntax and logical semantics, or can be a description model that uses that vocabulary to describe knowledge. OML has successfully been used at the Jet Propulsion Laboratory (JPL) in the context of Model Based Systems Engineering (MBSE), specifically to define the JPL systems engineering methodology in a highly modular and extensible way. Sirius has been used to define the authoring viewpoints that support such methodology. In this talk, we present how OML and Sirius can be used together, through the OML Rosetta Workbench, to streamline the development of an ontology-based modeling methodology and the authoring tools for it. The ideas will be demonstrated on a small example.
Maged Elaasar, NASA - Jet Propulsion Laboratory
Maged Elaasar is a Senior Software Systems Architect at NASA’s Jet Propulsion Laboratory (JPL) at the California Institute of Technology (Caltech). He technically leads a JPL-wide strategic R&D program called Integrated Model Centric Engineering (IMCE). Prior to that, Maged was a Senior Software Engineer at IBM, where he led the R&D of various software and systems modeling technologies. Maged is also the founder of Modelware Solutions, a company based in California that provides development, consulting, and training services in the area of model based engineering (MBE)
Architecture frameworks provide an approach to describing systems and the presentation of these elements and relationships to deliver the stakeholder needs. Essentially, frameworks provide templates for our engineering artefacts.
The design of a framework must accommodate a level of freedom in its usage; specific enough to answer the majority of stakeholder concerns whilst generic enough to allow for differences between projects. This balancing act often results in framework design being more generic to allow for a wider audience. Having an untailored framework, which is more ‘open’, can lead to creating inconsistent viewpoints.
Arcadia is one such framework as implemented through the Capella tool. The framework provides 4 perspectives/levels for product definition:
- The Operational Analysis, where the user needs are considered. Note: no concept of the System at this level.
- The System Analysis, where we define the contribution and scope of the System as a ‘black box’, identifying external interfaces, and top-level system functions.
- The Logical Architecture, where we break the System down into logical ‘blocks’ and decompose the functionality.
- The Physical Architecture, in which we define a (candidate) physical architecture, further decompose the functions, and deploy this functionality to the physical sub-systems, hardware, software and/or firmware.
In this talk, we acknowledge the strengths of the Arcadia framework, and the benefits it brings, whilst considering the need to tailor the generic viewpoints. We will provide examples of how we have adopted the generic Arcadia framework and further specified some of the viewpoints to meet the needs of our stakeholders. We will discuss future work looking at how we can translate these specialisations across other areas of the model. Finally, we will provide some suggestions and advice on tailoring views to meet your own needs and ensuring stakeholder engagement with the model.
CapellaDays2022 | Thales | Stairway to heaven: Climbing the very first stepsObeo
We MBSE enthusiasts love to imagine or witness sophisticated model-based engineering practices. We dream or in the best cases take advantage of digital continuity, automation, large-scale consistency, integration of disciplines, and end-to-end impact analyses.
However, not all of our architect and engineer fellows are in a situation in which they can appreciate sophistication of engineering practices the same way as we do. Entangled in everyday problems and facing the pressure to deliver, they perceive the introduction of model-based practices as an additional risk for a benefit that too often appears intangible.
Reaching the top of the stairs requires climbing the very first steps. This talk focuses on one of the most challenging aspects of MBSE deployment: lowering the height of the first steps. Paired with a pragmatic and incremental change management strategy, Capella and its add-ons are precious helpers.
Equivalences and diffrences between SysML and Arcadia / CapellaObeo
Designing complex and critical systems requires a level of rigor in engineering practices that only formalized and tool-supported modeling approaches can provide.
The Arcadia / Capella solution embeds a methodological guidance that constitutes one of its most significant originalities and success factors. By lowering the learning curve for systems engineers, Capella is an enabler for large scale MBSE adoption.
Largely inspired from several industry standards, Arcadia / Capella simultaneously form an enrichment and a simplification of SysML: a large proportion of the core concepts of the Arcadia method are aligned on the SysML ones, and most SysML diagrams have twins in Capella.
In this webinar, we will:
- Show to which extent Arcadia / Capella can be considered as a “SysML-like” solution, by illustrating diagrams and concepts equivalences
- Present the main differences between SysML and Arcadia / Capella
and provide rationales
Capella Days 2021 | Introduction to CAPELLA/ARCADIA and NASA Systems Engineer...Obeo
The NASA System Engineering (SE) handbook aims to provide general guidance and information on systems engineering, as it should be applied throughout NASA. The handbook introduces 3 common technical processes. One of these, is the System Design Process, describing the stakeholders expectations, requirements definition, logical decomposition and design solution definition. The 4 activities can be supported by a Model-Based Systems Engineering (MBSE) approach. To do so, an appropriate method and tool is necessary as the one provided by the ARChitecture Analysis & Design Integrated Approach.
ARCADIA, with its modeler CAPELLA, is a MBSE solution supporting system modeling activities. Based on 4 architectural layers, which are Operational Analysis, System Analysis, Logical and Physical Architecture, it is a structured architecture engineering method for defining and validating multi-domain systems.
This talk will present an educational overview of the ARCADIA methodology and System Design Process from the NASA SE, by introducing MBSE artefacts for space system.
The HUBBLE Space Telescope (HST) is a Cassegrain reflector telescope. Orbiting above the earth, HST elaborates a clear view of the universe free from the blurring and absorbing effects of the atmosphere. In order to illustrate the journey throughout CAPELLA, the HST will be introduced, as example, based on public information available.
Is your system robust to the loss of one or more functions? Does your system require interaction with other systems to operate safely?
Does the design and operational concept of the system include contingency means? Do these contingency means correctly mitigate the risks?
These and other similar considerations are becoming more important with the emergence of autonomous systems and complex systems of systems. The introduction of digital tools and in particular model-based systems engineering allows to capture the complexity of these products starting from the operational analysis and supporting the process throughout the whole product life cycle.
With ATICA, system architects and designers will be able to analyze safety implications starting from the conceptual needs and mission description; modeling risks associated to the system, assessing the probability of occurrence and severity, and deciding upon the needs of contingency and mitigation means. ATICA enriches the Arcadia framework and provides safety analysis capabilities for each step of the system definition, design, and verification process.
In this webinar, we will address an example with an autonomous vertical take-off and landing (VTOL) vehicle, conceived for operation in urban environments (urban air mobility). We will present the operational description and system architecture, and we will conduct the Functional Hazard Analysis (FHA) directly from Capella and aligned with the normative standards in force in the aeronautic industry (ARP-4761 / ED-135).
Finally, we will introduce safety analysis covering the logical and physical architecture levels, showcasing the use of Capella, Arcadia and ATICA for Fault Tree Analysis (FTA) and Failure Modes and Effects Analysis (FMEA).
***
Pablo López Negro
Chief Innovation Officer at Anzen Engineering
Pablo López Negro is the product owner of ATICA MBSA. He has been involved in the aerospace industry for nearly 10 years. Started as guidance, navigation and control engineer where he first discovered model-based / model-driven approaches and Capella. Then he evolved towards a system engineering position before becoming MBSE specialist and designer/developer of MBSE frameworks in Anzen.
Introduction to Capella and Arcadia with a Simple SystemObeo
Discover both Capella and Arcadia with an example of product design
Learn how to build a toy catapult system thanks to the Arcadia method and the Capella open MBSE tool.
In this Webinar, We:
- Distinguish between systems engineering, which is concerned with the entire design-build-test-deploy cycle of systems development, and systems architecture, which is concerned
with system concept development and architectural design.
- Contrast the System Modeling Language, SysML,
appropriate for systems engineering, with the more focused tool, Capella, and its associated methodology, Arcadia,
which is more appropriate for systems architecture development.
- Provide an overview of the attractive features of Capella,
from the point of view of initiating modelers into the language of systems architecture and briefly demonstrate our longer free public tutorial.
This webinar was driven by Professor Peter L. Jackson
Pr. Jackson is Head, Engineering Systems and Design Pillar at Singapore University of Technology and Design. He served as the Director of the Cornell University Systems Engineering Program and led the introduction of its online Master of Engineering degree program in systems engineering ranked in the top eight such programs by US News and World Report. He published over thirty articles and is the author of an introductory text on systems engineering, 'Getting Design Right: A Systems Approach'. He is a celebrated instructor of industrial engineering and the creator of dozens of experiential learning games and tools.
Modeling & Simulation of CubeSat-based Missions'Concept of OperationsObeo
Discover how Arcadia/Capella is used to model and simulate concept of operations scenarios for CubeSat-based missions. During this webinar, Danilo Pallamin de Almeida, who worked as a Space Systems Engineer for the NanosatC-BR2 mission at INPE, the Brazilian Institute for Space Research, will present how CubeSat-based missions have been modeled with Capella.
The model describing an initial architecture mission and concept of operations (CONOPS) is used to generate a script that configures a satellite simulator with the corresponding mission parameters.
You will see how it allows the INPE to:
- run concept of operations scenarios simulations,
- use the results for power/data-budget analyses and trade studies
CapellaDays2022 | NavalGroup | Closing the gap between traditional engineerin...Obeo
Closing the gap between traditional engineering and digital-native model-based driven engineering requires helping engineers to embrace new techniques. Naval Group decided to tackle the following issues: lack of interoperability with other systems, lack of bridge between functional definitions in PID schemas and MBSE physical layers, lack of documenting cross-layers relationships for a specific object's type.
Improving MBSE maturity with open-source tool Capella Obeo
MBSE aims at transitioning the Systems Engineering practice from a document-centric approach to a model-centric approach. It is envisioned to be the next shift enhancing significantly our systems engineering capacities, in order to cope with the steadily growing systems' complexity. Although MBSE has been a trending topic over the last few years, its adoption among systems engineers is still growing slowly.
In this presentation, Stephane Lacrampe will introduced some of the challenges in MBSE adoption and explained how the Arcadia method and the Capella tool are enablers for accelerating MBSE adoption among the systems engineering community.
Capella Days 2021 | A STEP towards Model-based: Case Study covering Conceptua...Obeo
STEP (Spherical Tokamak for Energy Production) is a £220M project aiming to develop a conceptual design for a First of a Kind (FOAK) commercially viable Fusion Power Plant by 2024.
Designing a power plant at this scale comes with immense challenges: Systems engineering approach is relatively new to the industry, where the industry has been heavily research based and engineering processes are not fully in place. UKAEA, the organisation running the STEP project, is applying Model-Based Systems Engineering using the Capella tool.
The focus of our approach in managing the complexity of the system is to perform system analysis and logical architecture analysis, to generate engineering artefacts from the model. Through NGO (Needs, Goals, Objectives) analysis key system capabilities were realised to functional chains, which forms the basis for further refinement of the Logical Architecture. The differentiation between logical and physical architectures has ensured that the design stays at the logical space and the team focuses on defining the problem space. This approach has improved interface management process, by creating model-based interface documents, using the model as ‘single source of truth’ to achieve consistency. The architecture definition activities allowed early formalisation of the textual requirements, to drive detailed engineering design in the next phase.
Adopting Capella comes with challenges - one of which stems from the unique characteristic of the concept phase – the need to generate architectural variants and evaluating them. The framework and the language are limited in performing variant modelling, a topic UKAEA plans to investigate further. Another challenge was that middle-out approach was favoured for STEP whereas Arcadia method prefers the top-down approach.
Throughout this journey, adopting Capella with its use-friendly interfaces has allowed us to better engage with the programme in the MBSE approach and indoctrinate better SE practices.
Model-Based Systems Engineering (MBSE) is an ambiguous concept that means many things to many different people. The purpose of this presentation is to “de-mystify” MBSE, with the intent of moving the sub-discipline forward. Model-Based Systems Engineering was envisioned to manage the increasing complexity within systems and System of Systems (SoS). This presentation defines MBSE as the formalized application of modeling (static and dynamic) to support system design and analysis, throughout all phases of the system lifecycle, and through the collection of modeling languages, structures, model-based processes, and presentation frameworks used to support the discipline of systems engineering in a model-based or model-driven context. Using this definition, the components of MBSE (modeling languages, processes, structures, and presentation frameworks) are defined. The current state of MBSE is then evaluated against a set of effective measures. Finally, this presents a vision for the future direction of MBSE.
In the last three years CILAS has been tailoring and applying the Arcadia methodology to several international projects related to complex optronics products development. Even though the implementation is not yet thorough and systemic within the company, CILAS is already reaping benefits of this approach on several fronts (e.g. communication, identification of optimization opportunities, knowledge capitalization etc). All in all Arcadia is a powerful methodology that significantly helps CILAS reinforcing its core skills and meeting its objectives in very challenging sectors.
A common need in system architecture design is to verify that if the architect is correct and can satisfy its requirements.
Execution of system architect model means to interact with state machines to test system’s control logic. It can verify if the logical sequences of functions and interfaces in different scenarios are desired.
However, only sequence itself is not enough to verify its consequence or output. So we need each function to do what it is supposed to do during model execution to verify its output, and that is what we called “simulation”.
This presentation introduced how to embed Python or MATLAB® codes inside functions to do “simulation” within Capella.
We know change can be intimidating. The coming release of SysML V2 can seem intimidating, as it is a product of 70 organizations and 170 people collaborating. Join us for our next webinar, “Dissecting SysML V2,” with Systems Engineer, Lilleigh Stevie. We will look closely at the next generation of OMG’s modeling language by covering its background, purpose and objectives, KerML, familiar and new concepts, pilot implementation, and where this will take us in the future. There will be a designated time at the end for questions, so bring any you may have with you. Register today and we will see you there!
Model-based systems engineering is everywhere - everyone talks about it, everyone wants to use it, but what is actually behind it? This question will be outlined by means of a playful approach and a real problem: "I pack my suitcase and take with me...".
Based on this problem, we will successively use the game to pack the suitcase with the help of SE and finally MBSE and present it by means of a small demonstration. Let's go together on the hopefully soon journey and pack our suitcase.
MBSE with Arcadia method step-by-step System Analysis.pdfHelder Castro
The Operational Analysis described is the previous article, MBSE with Arcadia method step-by-step: Operational Analysis [1], involves defining and creating a domain model, independently of the future system to be realized. The principle is to create a level of abstraction from the system under study in order to focus on the needs of the different stakeholders.
The System Analysis level, on the other hand, is where the System-of-Interest (SoI) to be defined emerges. The following questions for the system definition needs to be answered:
• What must the system do?
• What are the external interfaces to the system?
In order to answer the first question, the expected behaviour is modelled as Functions.
[Capella Days 2020] Innovating with MBSE – Medical Device ExampleObeo
by Tony Komar (Siemens)
Sustained innovation is the goal of many development organizations. Sustaining innovation is depicted on an Innovation as matrix as the result of a well-defined problem, and a well-defined domain definition. An example will be presented how an MBSE tool, based on open-source tool Capella, can enhance both the problem definition and domain definition of a ventilator. It will show how the MBSE tool enhanced the understanding of the problem, and how that understanding can lead to an innovative solution.
Leveraging Alf for SysML, Part 2: More Effective Trade Study ModelingEd Seidewitz
Alf is the OMG-standard textual language specifically designed for specifying executable behavior in the context of graphical, executable UML and SysML models. It is the best alternative to using complicated activity diagrams or scripting languages not designed for use in models. Part 2 of this tutorial focuses on leveraging Alf in SysML models for studying trade-offs between design variants.
Scripting with Python to interact with Capella modelObeo
Scripting with Python to interact with Capella model
Have you ever wanted to easily extract engineering data from your Capella model? Have you ever wanted to easily modify your Capella model and import information into it to update it?
This webinar presents a prototype Capella Add-on that will address several example use cases
- Read information from a Capella model and export to Excel, with queries
- Update information in a Capella model
- Add elements in a Capella model
This new Capella add-on uses a common scripting language, not dedicated to Capella: Python.
- It offers the capacity to use sample scripts addressing basic need and to build its own scripts, with libraries for common add-ons (Requirement, PVMT)
- It’s easy to share, to use, has high customization capabilities
support of Capella and Team for Capella, wide compatibility with Capella versions
It is presented by :
- Sophie Plazanet (Thales Group) - MBSE Specialist
Master of Engineering & Master of Research in Advanced Systems & Robotics – Arts & Métiers ParisTech
- Arnaud Dieumegard (Obeo) - Eclipse Modeling Consultant
Ph.D. in Reliability for Systems and Software - INP Toulouse
To illustrate the examples, you'll find the videos on this playlist: https://bit.ly/capella_webinar_211216_playlist
The openCAESAR project provides an EMF-based implementation of the Ontological Modeling Language (OML), which simplifies the use of semantic web ontologies for modeling and analysis. An OML model can be either be a vocabulary model that defines the terms and rules in a business domain with precise syntax and logical semantics, or can be a description model that uses that vocabulary to describe knowledge. OML has successfully been used at the Jet Propulsion Laboratory (JPL) in the context of Model Based Systems Engineering (MBSE), specifically to define the JPL systems engineering methodology in a highly modular and extensible way. Sirius has been used to define the authoring viewpoints that support such methodology. In this talk, we present how OML and Sirius can be used together, through the OML Rosetta Workbench, to streamline the development of an ontology-based modeling methodology and the authoring tools for it. The ideas will be demonstrated on a small example.
Maged Elaasar, NASA - Jet Propulsion Laboratory
Maged Elaasar is a Senior Software Systems Architect at NASA’s Jet Propulsion Laboratory (JPL) at the California Institute of Technology (Caltech). He technically leads a JPL-wide strategic R&D program called Integrated Model Centric Engineering (IMCE). Prior to that, Maged was a Senior Software Engineer at IBM, where he led the R&D of various software and systems modeling technologies. Maged is also the founder of Modelware Solutions, a company based in California that provides development, consulting, and training services in the area of model based engineering (MBE)
Architecture frameworks provide an approach to describing systems and the presentation of these elements and relationships to deliver the stakeholder needs. Essentially, frameworks provide templates for our engineering artefacts.
The design of a framework must accommodate a level of freedom in its usage; specific enough to answer the majority of stakeholder concerns whilst generic enough to allow for differences between projects. This balancing act often results in framework design being more generic to allow for a wider audience. Having an untailored framework, which is more ‘open’, can lead to creating inconsistent viewpoints.
Arcadia is one such framework as implemented through the Capella tool. The framework provides 4 perspectives/levels for product definition:
- The Operational Analysis, where the user needs are considered. Note: no concept of the System at this level.
- The System Analysis, where we define the contribution and scope of the System as a ‘black box’, identifying external interfaces, and top-level system functions.
- The Logical Architecture, where we break the System down into logical ‘blocks’ and decompose the functionality.
- The Physical Architecture, in which we define a (candidate) physical architecture, further decompose the functions, and deploy this functionality to the physical sub-systems, hardware, software and/or firmware.
In this talk, we acknowledge the strengths of the Arcadia framework, and the benefits it brings, whilst considering the need to tailor the generic viewpoints. We will provide examples of how we have adopted the generic Arcadia framework and further specified some of the viewpoints to meet the needs of our stakeholders. We will discuss future work looking at how we can translate these specialisations across other areas of the model. Finally, we will provide some suggestions and advice on tailoring views to meet your own needs and ensuring stakeholder engagement with the model.
CapellaDays2022 | Thales | Stairway to heaven: Climbing the very first stepsObeo
We MBSE enthusiasts love to imagine or witness sophisticated model-based engineering practices. We dream or in the best cases take advantage of digital continuity, automation, large-scale consistency, integration of disciplines, and end-to-end impact analyses.
However, not all of our architect and engineer fellows are in a situation in which they can appreciate sophistication of engineering practices the same way as we do. Entangled in everyday problems and facing the pressure to deliver, they perceive the introduction of model-based practices as an additional risk for a benefit that too often appears intangible.
Reaching the top of the stairs requires climbing the very first steps. This talk focuses on one of the most challenging aspects of MBSE deployment: lowering the height of the first steps. Paired with a pragmatic and incremental change management strategy, Capella and its add-ons are precious helpers.
Equivalences and diffrences between SysML and Arcadia / CapellaObeo
Designing complex and critical systems requires a level of rigor in engineering practices that only formalized and tool-supported modeling approaches can provide.
The Arcadia / Capella solution embeds a methodological guidance that constitutes one of its most significant originalities and success factors. By lowering the learning curve for systems engineers, Capella is an enabler for large scale MBSE adoption.
Largely inspired from several industry standards, Arcadia / Capella simultaneously form an enrichment and a simplification of SysML: a large proportion of the core concepts of the Arcadia method are aligned on the SysML ones, and most SysML diagrams have twins in Capella.
In this webinar, we will:
- Show to which extent Arcadia / Capella can be considered as a “SysML-like” solution, by illustrating diagrams and concepts equivalences
- Present the main differences between SysML and Arcadia / Capella
and provide rationales
Capella Days 2021 | Introduction to CAPELLA/ARCADIA and NASA Systems Engineer...Obeo
The NASA System Engineering (SE) handbook aims to provide general guidance and information on systems engineering, as it should be applied throughout NASA. The handbook introduces 3 common technical processes. One of these, is the System Design Process, describing the stakeholders expectations, requirements definition, logical decomposition and design solution definition. The 4 activities can be supported by a Model-Based Systems Engineering (MBSE) approach. To do so, an appropriate method and tool is necessary as the one provided by the ARChitecture Analysis & Design Integrated Approach.
ARCADIA, with its modeler CAPELLA, is a MBSE solution supporting system modeling activities. Based on 4 architectural layers, which are Operational Analysis, System Analysis, Logical and Physical Architecture, it is a structured architecture engineering method for defining and validating multi-domain systems.
This talk will present an educational overview of the ARCADIA methodology and System Design Process from the NASA SE, by introducing MBSE artefacts for space system.
The HUBBLE Space Telescope (HST) is a Cassegrain reflector telescope. Orbiting above the earth, HST elaborates a clear view of the universe free from the blurring and absorbing effects of the atmosphere. In order to illustrate the journey throughout CAPELLA, the HST will be introduced, as example, based on public information available.
Is your system robust to the loss of one or more functions? Does your system require interaction with other systems to operate safely?
Does the design and operational concept of the system include contingency means? Do these contingency means correctly mitigate the risks?
These and other similar considerations are becoming more important with the emergence of autonomous systems and complex systems of systems. The introduction of digital tools and in particular model-based systems engineering allows to capture the complexity of these products starting from the operational analysis and supporting the process throughout the whole product life cycle.
With ATICA, system architects and designers will be able to analyze safety implications starting from the conceptual needs and mission description; modeling risks associated to the system, assessing the probability of occurrence and severity, and deciding upon the needs of contingency and mitigation means. ATICA enriches the Arcadia framework and provides safety analysis capabilities for each step of the system definition, design, and verification process.
In this webinar, we will address an example with an autonomous vertical take-off and landing (VTOL) vehicle, conceived for operation in urban environments (urban air mobility). We will present the operational description and system architecture, and we will conduct the Functional Hazard Analysis (FHA) directly from Capella and aligned with the normative standards in force in the aeronautic industry (ARP-4761 / ED-135).
Finally, we will introduce safety analysis covering the logical and physical architecture levels, showcasing the use of Capella, Arcadia and ATICA for Fault Tree Analysis (FTA) and Failure Modes and Effects Analysis (FMEA).
***
Pablo López Negro
Chief Innovation Officer at Anzen Engineering
Pablo López Negro is the product owner of ATICA MBSA. He has been involved in the aerospace industry for nearly 10 years. Started as guidance, navigation and control engineer where he first discovered model-based / model-driven approaches and Capella. Then he evolved towards a system engineering position before becoming MBSE specialist and designer/developer of MBSE frameworks in Anzen.
Introduction to Capella and Arcadia with a Simple SystemObeo
Discover both Capella and Arcadia with an example of product design
Learn how to build a toy catapult system thanks to the Arcadia method and the Capella open MBSE tool.
In this Webinar, We:
- Distinguish between systems engineering, which is concerned with the entire design-build-test-deploy cycle of systems development, and systems architecture, which is concerned
with system concept development and architectural design.
- Contrast the System Modeling Language, SysML,
appropriate for systems engineering, with the more focused tool, Capella, and its associated methodology, Arcadia,
which is more appropriate for systems architecture development.
- Provide an overview of the attractive features of Capella,
from the point of view of initiating modelers into the language of systems architecture and briefly demonstrate our longer free public tutorial.
This webinar was driven by Professor Peter L. Jackson
Pr. Jackson is Head, Engineering Systems and Design Pillar at Singapore University of Technology and Design. He served as the Director of the Cornell University Systems Engineering Program and led the introduction of its online Master of Engineering degree program in systems engineering ranked in the top eight such programs by US News and World Report. He published over thirty articles and is the author of an introductory text on systems engineering, 'Getting Design Right: A Systems Approach'. He is a celebrated instructor of industrial engineering and the creator of dozens of experiential learning games and tools.
Modeling & Simulation of CubeSat-based Missions'Concept of OperationsObeo
Discover how Arcadia/Capella is used to model and simulate concept of operations scenarios for CubeSat-based missions. During this webinar, Danilo Pallamin de Almeida, who worked as a Space Systems Engineer for the NanosatC-BR2 mission at INPE, the Brazilian Institute for Space Research, will present how CubeSat-based missions have been modeled with Capella.
The model describing an initial architecture mission and concept of operations (CONOPS) is used to generate a script that configures a satellite simulator with the corresponding mission parameters.
You will see how it allows the INPE to:
- run concept of operations scenarios simulations,
- use the results for power/data-budget analyses and trade studies
CapellaDays2022 | NavalGroup | Closing the gap between traditional engineerin...Obeo
Closing the gap between traditional engineering and digital-native model-based driven engineering requires helping engineers to embrace new techniques. Naval Group decided to tackle the following issues: lack of interoperability with other systems, lack of bridge between functional definitions in PID schemas and MBSE physical layers, lack of documenting cross-layers relationships for a specific object's type.
Improving MBSE maturity with open-source tool Capella Obeo
MBSE aims at transitioning the Systems Engineering practice from a document-centric approach to a model-centric approach. It is envisioned to be the next shift enhancing significantly our systems engineering capacities, in order to cope with the steadily growing systems' complexity. Although MBSE has been a trending topic over the last few years, its adoption among systems engineers is still growing slowly.
In this presentation, Stephane Lacrampe will introduced some of the challenges in MBSE adoption and explained how the Arcadia method and the Capella tool are enablers for accelerating MBSE adoption among the systems engineering community.
Capella Days 2021 | A STEP towards Model-based: Case Study covering Conceptua...Obeo
STEP (Spherical Tokamak for Energy Production) is a £220M project aiming to develop a conceptual design for a First of a Kind (FOAK) commercially viable Fusion Power Plant by 2024.
Designing a power plant at this scale comes with immense challenges: Systems engineering approach is relatively new to the industry, where the industry has been heavily research based and engineering processes are not fully in place. UKAEA, the organisation running the STEP project, is applying Model-Based Systems Engineering using the Capella tool.
The focus of our approach in managing the complexity of the system is to perform system analysis and logical architecture analysis, to generate engineering artefacts from the model. Through NGO (Needs, Goals, Objectives) analysis key system capabilities were realised to functional chains, which forms the basis for further refinement of the Logical Architecture. The differentiation between logical and physical architectures has ensured that the design stays at the logical space and the team focuses on defining the problem space. This approach has improved interface management process, by creating model-based interface documents, using the model as ‘single source of truth’ to achieve consistency. The architecture definition activities allowed early formalisation of the textual requirements, to drive detailed engineering design in the next phase.
Adopting Capella comes with challenges - one of which stems from the unique characteristic of the concept phase – the need to generate architectural variants and evaluating them. The framework and the language are limited in performing variant modelling, a topic UKAEA plans to investigate further. Another challenge was that middle-out approach was favoured for STEP whereas Arcadia method prefers the top-down approach.
Throughout this journey, adopting Capella with its use-friendly interfaces has allowed us to better engage with the programme in the MBSE approach and indoctrinate better SE practices.
Model-Based Systems Engineering (MBSE) is an ambiguous concept that means many things to many different people. The purpose of this presentation is to “de-mystify” MBSE, with the intent of moving the sub-discipline forward. Model-Based Systems Engineering was envisioned to manage the increasing complexity within systems and System of Systems (SoS). This presentation defines MBSE as the formalized application of modeling (static and dynamic) to support system design and analysis, throughout all phases of the system lifecycle, and through the collection of modeling languages, structures, model-based processes, and presentation frameworks used to support the discipline of systems engineering in a model-based or model-driven context. Using this definition, the components of MBSE (modeling languages, processes, structures, and presentation frameworks) are defined. The current state of MBSE is then evaluated against a set of effective measures. Finally, this presents a vision for the future direction of MBSE.
In the last three years CILAS has been tailoring and applying the Arcadia methodology to several international projects related to complex optronics products development. Even though the implementation is not yet thorough and systemic within the company, CILAS is already reaping benefits of this approach on several fronts (e.g. communication, identification of optimization opportunities, knowledge capitalization etc). All in all Arcadia is a powerful methodology that significantly helps CILAS reinforcing its core skills and meeting its objectives in very challenging sectors.
A common need in system architecture design is to verify that if the architect is correct and can satisfy its requirements.
Execution of system architect model means to interact with state machines to test system’s control logic. It can verify if the logical sequences of functions and interfaces in different scenarios are desired.
However, only sequence itself is not enough to verify its consequence or output. So we need each function to do what it is supposed to do during model execution to verify its output, and that is what we called “simulation”.
This presentation introduced how to embed Python or MATLAB® codes inside functions to do “simulation” within Capella.
We know change can be intimidating. The coming release of SysML V2 can seem intimidating, as it is a product of 70 organizations and 170 people collaborating. Join us for our next webinar, “Dissecting SysML V2,” with Systems Engineer, Lilleigh Stevie. We will look closely at the next generation of OMG’s modeling language by covering its background, purpose and objectives, KerML, familiar and new concepts, pilot implementation, and where this will take us in the future. There will be a designated time at the end for questions, so bring any you may have with you. Register today and we will see you there!
Model-based systems engineering is everywhere - everyone talks about it, everyone wants to use it, but what is actually behind it? This question will be outlined by means of a playful approach and a real problem: "I pack my suitcase and take with me...".
Based on this problem, we will successively use the game to pack the suitcase with the help of SE and finally MBSE and present it by means of a small demonstration. Let's go together on the hopefully soon journey and pack our suitcase.
MBSE with Arcadia method step-by-step System Analysis.pdfHelder Castro
The Operational Analysis described is the previous article, MBSE with Arcadia method step-by-step: Operational Analysis [1], involves defining and creating a domain model, independently of the future system to be realized. The principle is to create a level of abstraction from the system under study in order to focus on the needs of the different stakeholders.
The System Analysis level, on the other hand, is where the System-of-Interest (SoI) to be defined emerges. The following questions for the system definition needs to be answered:
• What must the system do?
• What are the external interfaces to the system?
In order to answer the first question, the expected behaviour is modelled as Functions.
[Capella Days 2020] Innovating with MBSE – Medical Device ExampleObeo
by Tony Komar (Siemens)
Sustained innovation is the goal of many development organizations. Sustaining innovation is depicted on an Innovation as matrix as the result of a well-defined problem, and a well-defined domain definition. An example will be presented how an MBSE tool, based on open-source tool Capella, can enhance both the problem definition and domain definition of a ventilator. It will show how the MBSE tool enhanced the understanding of the problem, and how that understanding can lead to an innovative solution.
Leveraging Alf for SysML, Part 2: More Effective Trade Study ModelingEd Seidewitz
Alf is the OMG-standard textual language specifically designed for specifying executable behavior in the context of graphical, executable UML and SysML models. It is the best alternative to using complicated activity diagrams or scripting languages not designed for use in models. Part 2 of this tutorial focuses on leveraging Alf in SysML models for studying trade-offs between design variants.
Scripting with Python to interact with Capella modelObeo
Scripting with Python to interact with Capella model
Have you ever wanted to easily extract engineering data from your Capella model? Have you ever wanted to easily modify your Capella model and import information into it to update it?
This webinar presents a prototype Capella Add-on that will address several example use cases
- Read information from a Capella model and export to Excel, with queries
- Update information in a Capella model
- Add elements in a Capella model
This new Capella add-on uses a common scripting language, not dedicated to Capella: Python.
- It offers the capacity to use sample scripts addressing basic need and to build its own scripts, with libraries for common add-ons (Requirement, PVMT)
- It’s easy to share, to use, has high customization capabilities
support of Capella and Team for Capella, wide compatibility with Capella versions
It is presented by :
- Sophie Plazanet (Thales Group) - MBSE Specialist
Master of Engineering & Master of Research in Advanced Systems & Robotics – Arts & Métiers ParisTech
- Arnaud Dieumegard (Obeo) - Eclipse Modeling Consultant
Ph.D. in Reliability for Systems and Software - INP Toulouse
To illustrate the examples, you'll find the videos on this playlist: https://bit.ly/capella_webinar_211216_playlist
MoDELS'16 presentation: Integration of a Graph-Based Model Indexer in Commerc...Antonio García-Domínguez
In this MoDELS'16 paper, we show how the Hawk model indexer was extended to index Modelio models, and how it was embedded into the Constellation collaboration server from SOFTEAM to allow for efficient querying and metric extraction from its web-based interface.
The presentation shows a first version of a Domain Specific Language (DSL) based on Eclipse XText, the tooling provided with it and the way to generate the necessary XSD and WSDL artifacts.
Explaining how OSGi helps creating extensible systems. The source code examples for this presentation can be found here: https://bitbucket.org/paul_bakker/modularity-patterns-with-osgi-examples
Learn how to develop an AndroidApp from a senior developer — for free! We decided to make one of our “Showmaxers teaching Showmaxers” events public. This one is from our Android developer Michal Ursiny. Check it out.
What you will learn and do:
- Introduction to Android development and what it takes to develop for Android - it’s actually pretty easy to start compared to other mobile platforms
- Java vs Kotlin - you can use both, but we recommend Kotlin
- How to create new project using Android Studio, the official IDE for Android development
- How to choose the appropriate minimum SDK version
- Understanding basic project structure:
sources
resources
AndroidManifest.xml
build.gradle
- You will run the demo project generated by Android Studio and modify it
- The basic building blocks:
Activity
Fragment
View
- How to build basic layouts using resources and themes
- The challenges - lifecycles and why to use viewmodels
- Permissions - how to access REST APIs using Retrofit library and why using third party image libraries is a good idea
Getting started
Download Android Studio - the official IDE based on IntelliJ IDEA. Configure your emulator or enable developer mode on your device and connect to the computer. Get acquainted with Android Studio.
Originally, the sample project used within the tutorial was targeting our internal Showmax Search API. It was changed to use GitHub Users Search API so it’s available and useful for everyone.
On our blog on https://tech.showmax.com/2021/02/android-crashcourse/ you can watch Michal’s easy-to-digest and comprehensive presentation embedded from YouTube.
Or just read the deck and learn the basics.
Try building the app yourself by following the shared sample project: https://github.com/Showmax/GithubUsersSearch
DDS Advanced Tutorial - OMG June 2013 Berlin MeetingJaime Martin Losa
An extended, in-depth tutorial explaining how to fully exploit the standard's unique communication capabilities.Presented at the OMG June 2013 Berlin Meeting.
Users upgrading to DDS from a homegrown solution or a legacy-messaging infrastructure often limit themselves to using its most basic publish-subscribe features. This allows applications to take advantage of reliable multicast and other performance and scalability features of the DDS wire protocol, as well as the enhanced robustness of the DDS peer-to-peer architecture. However, applications that do not use DDS's data-centricity do not take advantage of many of its QoS-related, scalability and availability features, such as the KeepLast History Cache, Instance Ownership and Deadline Monitoring. As a consequence some developers duplicate these features in custom application code, resulting in increased costs, lower performance, and compromised portability and interoperability.
This tutorial will formally define the data-centric publish-subscribe model as specified in the OMG DDS specification and define a set of best-practice guidelines and patterns for the design and implementation of systems based on DDS.
UK INCOSE Annual Systems Engineering Conference. Case Study - Implementing TR...Nic Plum
Companion paper to a presentation given to the UK INCOSE Annual Systems Engineering Conference (ASEC) 2010 at Heythrop Park. See http://www.incoseonline.org.uk/Program_Files/Calendar/Show_Event_Details.aspx?
CatID=Events&EventID=138
Describes how an implementation of TRAK, a generic architecture framework, was implemented using Sparx Systems Enterprise Architect UML modelling tool.
TRAK is defined at http://trakviewpoints.sourceforge.net and http://trakmetamodel.sourceforge.net
Similar to Introduction to the OMG Systems Modeling Language (SysML), Version 2 (20)
Leveraging Alf for SysML, Part 1: Better Simulation ModelingEd Seidewitz
Alf is the OMG-standard textual language specifically designed for specifying executable behavior in the context of graphical, executable UML and SysML models. It is the best alternative to using complicated activity diagrams or scripting languages not designed for use in models. Part 1 of this tutorial describes how to take advantage of Alf to create better SysML simulation models more easily than ever before, including detailed behaviors for blocks in the context of state machine, activity and operation models.
The Very Model of a Modern MetamodelerEd Seidewitz
Philosophers have been talking about metaphysics since Aristotle. Logicians have used metalanguages for 80 years. And, in the last 50 years, computer scientists have produced metaobjects, metaclasses and metamodels. “Going meta” is now even part of the popular culture. What is this all about?
It is about the incredibly powerful human ability to reflect on what we are doing. Bringing this capability to our modeling languages, we can create languages able to express their own definitions. But, with real semantic formalization, we also open up the possibility of creating tools that can reflect on the very models they are being used to create. What might this mean for the next generation of modeling languages and tools?
This presentations goes meta, to reflect on reflection and try to figure it out.
Model Driven Architecture without AutomationEd Seidewitz
This is an old presentation, but still interesting. An example of using models as primary artifacts for communication during a development effort, even without code generation.
NOTE: This presentation used to be on my Slideshare, but it seems to have gotten deleted, so I have uploaded it again.
Using Alf with Cameo Simulation Toolkit - Part 2: ModelingEd Seidewitz
Alf is an OMG-standard textual language with a familiar Java-like syntax, but it is designed specifically to be used in the context of graphical, executable UML and SysML models. This language is available for use in No Magic's Cameo Simulation Toolkit (CST) v18.5 to write expressions and behaviors in executable UML. This presentation follows on from "Using Alf with Cameo Simulation Toolkit - Part 1", covering the use of Alf for specifying behaviors in models of multiple, communicating objects, including synchronous operation calling and asynchronous signal sending.
Using Alf with Cameo Simulation Toolkit - Part 1: BasicsEd Seidewitz
Alf is an OMG-standard textual language with a familiar Java-like syntax, but it is designed specifically to be used in the context of graphical, executable UML and SysML models. This language is available for use in No Magic's Cameo Simulation Toolkit (CST) v18.5 to write expressions and behaviors in executable UML. Behind the scenes, Alf is actually compiled into UML activity models, which are then automatically integrated into your overall model, so they can be seamlessly executed using CST. This presentation gives an introduction to the Alf language, a tutorial on how to use it in CST and hands-on exercises to try yourself. You will be amazed at how much quicker and easier it is to write three lines of Alf code, rather than create by hand an equivalent activity model of 20 or more elements!
Programming in UML: An Introduction to fUML 1.3 and Alf 1.1Ed Seidewitz
Based on a tutorial presentation given at the OMG Executable UML Information Day, this version of the presentation has been updated for fUML 1.3 and Alf 1.1, the latest versions as of this upload.
Hands On With the Alf Action Language: Making Executable Modeling Even EasierEd Seidewitz
Do you use the industry-leading model execution capabilities provided by Cameo Simulation Toolkit (CST)? Do you love being able to simulate systems using state machines and activities? But, on the other hand, do you dread the complexity of using activity diagrams to code really detailed behavior? Or do you get annoyed by having limited access your model state if you use a scripting language instead? Now there is a solution! The Alf Plugin gives you the ability to use the OMG-standard Alf action language to write expressions and behaviors in models executed using CST. Alf is a textual language with a familiar Java-like syntax, but it is designed specifically to be used in the context of graphical, executable UML and SysML models. Indeed, behind the scenes, Alf is actually compiled into UML activity models, which are then automatically integrated into your overall model, so they can be seamlessly executed using CST. This tutorial gives you an introduction to the Alf language, instruction on how to install and use the Alf Plugin with CST, and a chance to try it out hands-on. You will be amazed at how much quicker and easier it is to write three lines of Alf code, rather than create by hand an equivalent activity model of 20 or more elements!
Standards-Based Executable UML: Today's Reality and Tomorrow's PromiseEd Seidewitz
This webinar demonstrates the practical realization of standards-based executable modeling in UML, showing its importance for moving forward in a number of, perhaps, unexpected areas, including agile development methods, multi-core programming and model-based system engineering. Today’s Executable UML is based on the OMG’s Foundational UML (fUML) standard, for executable object-oriented and activity modeling, and the Action Language for fUML (Alf) standard, which defines a corresponding textual representation. But this is only the beginning. Additional Executable UML standards are being built on this foundation, including recent ones for composite structure and state machines.
The Unified Modeling Language (UML) is, of course, a modeling language. But there are now standard, executable semantics for a subset of UML (known as Foundational UML or fUML) and a standard language that provides a textual representation for this subset (the Action Language for fUML or Alf). Doesn’t this just make at least this subset of UML into a programming language?
Well, yes. After all, a programming language is really itself a modeling language for modellng computations that can actually be executed on computation hardware. In this view, all programs are models, but only some models, the executable models, are programs. Which means that an “executable modelling language” is, by definition, a programming language.
But is this a good thing? That is the question explored in this presentation, which argues that the answer is “yes”. And, moreover, UML as a programming language may, in fact, be important for moving forward in a number of, perhaps, unexpected areas, including agile development methods and programming for multi-core architectures.
The Unified Modeling Language (UML) has arguably succeeded in becoming the most commonly used modeling notation for software development. But “modeling” in the software community seems largely to mean simply drawing pictures, either to represent the problem domain or to blueprint a solution, without a precise enough meaning to fully specify the functionality of the system being developed. As a result, the UML standard,S up to and including UML 2.4.1, do not define the semantics of UML models at all precisely.
Nevertheless, there has also long been an interest in models that are more precise, even to the extent that they may be executed in their own right. It has taken a while for this viewpoint to penetrate into the mainstream of UML usage. But there has been in a great deal of work in recent years toward the standardization of the formal semantics of UML models – the “meaning” behind the pictures: the Foundational UML (fUML) specification adopted in 2008; the Action Language for fUML (Alf), adopted in 2010; the UML 2.5 specification (which includes a semantics conformance point for the first time); and the Precise Semantics of UML Composite Structures.
This presentation reviews the state of this work and the implications in practice of bringing real meaning to UML.
A presentation on the UML 2.5 specification simplification effort, presented at the 3rd Biannual Workshop on Eclipse Open Source Software and OMG Open Specifications.
Explore the innovative world of trenchless pipe repair with our comprehensive guide, "The Benefits and Techniques of Trenchless Pipe Repair." This document delves into the modern methods of repairing underground pipes without the need for extensive excavation, highlighting the numerous advantages and the latest techniques used in the industry.
Learn about the cost savings, reduced environmental impact, and minimal disruption associated with trenchless technology. Discover detailed explanations of popular techniques such as pipe bursting, cured-in-place pipe (CIPP) lining, and directional drilling. Understand how these methods can be applied to various types of infrastructure, from residential plumbing to large-scale municipal systems.
Ideal for homeowners, contractors, engineers, and anyone interested in modern plumbing solutions, this guide provides valuable insights into why trenchless pipe repair is becoming the preferred choice for pipe rehabilitation. Stay informed about the latest advancements and best practices in the field.
Sachpazis:Terzaghi Bearing Capacity Estimation in simple terms with Calculati...Dr.Costas Sachpazis
Terzaghi's soil bearing capacity theory, developed by Karl Terzaghi, is a fundamental principle in geotechnical engineering used to determine the bearing capacity of shallow foundations. This theory provides a method to calculate the ultimate bearing capacity of soil, which is the maximum load per unit area that the soil can support without undergoing shear failure. The Calculation HTML Code included.
TECHNICAL TRAINING MANUAL GENERAL FAMILIARIZATION COURSEDuvanRamosGarzon1
AIRCRAFT GENERAL
The Single Aisle is the most advanced family aircraft in service today, with fly-by-wire flight controls.
The A318, A319, A320 and A321 are twin-engine subsonic medium range aircraft.
The family offers a choice of engines
Event Management System Vb Net Project Report.pdfKamal Acharya
In present era, the scopes of information technology growing with a very fast .We do not see any are untouched from this industry. The scope of information technology has become wider includes: Business and industry. Household Business, Communication, Education, Entertainment, Science, Medicine, Engineering, Distance Learning, Weather Forecasting. Carrier Searching and so on.
My project named “Event Management System” is software that store and maintained all events coordinated in college. It also helpful to print related reports. My project will help to record the events coordinated by faculties with their Name, Event subject, date & details in an efficient & effective ways.
In my system we have to make a system by which a user can record all events coordinated by a particular faculty. In our proposed system some more featured are added which differs it from the existing system such as security.
CFD Simulation of By-pass Flow in a HRSG module by R&R Consult.pptxR&R Consult
CFD analysis is incredibly effective at solving mysteries and improving the performance of complex systems!
Here's a great example: At a large natural gas-fired power plant, where they use waste heat to generate steam and energy, they were puzzled that their boiler wasn't producing as much steam as expected.
R&R and Tetra Engineering Group Inc. were asked to solve the issue with reduced steam production.
An inspection had shown that a significant amount of hot flue gas was bypassing the boiler tubes, where the heat was supposed to be transferred.
R&R Consult conducted a CFD analysis, which revealed that 6.3% of the flue gas was bypassing the boiler tubes without transferring heat. The analysis also showed that the flue gas was instead being directed along the sides of the boiler and between the modules that were supposed to capture the heat. This was the cause of the reduced performance.
Based on our results, Tetra Engineering installed covering plates to reduce the bypass flow. This improved the boiler's performance and increased electricity production.
It is always satisfying when we can help solve complex challenges like this. Do your systems also need a check-up or optimization? Give us a call!
Work done in cooperation with James Malloy and David Moelling from Tetra Engineering.
More examples of our work https://www.r-r-consult.dk/en/cases-en/
COLLEGE BUS MANAGEMENT SYSTEM PROJECT REPORT.pdfKamal Acharya
The College Bus Management system is completely developed by Visual Basic .NET Version. The application is connect with most secured database language MS SQL Server. The application is develop by using best combination of front-end and back-end languages. The application is totally design like flat user interface. This flat user interface is more attractive user interface in 2017. The application is gives more important to the system functionality. The application is to manage the student’s details, driver’s details, bus details, bus route details, bus fees details and more. The application has only one unit for admin. The admin can manage the entire application. The admin can login into the application by using username and password of the admin. The application is develop for big and small colleges. It is more user friendly for non-computer person. Even they can easily learn how to manage the application within hours. The application is more secure by the admin. The system will give an effective output for the VB.Net and SQL Server given as input to the system. The compiled java program given as input to the system, after scanning the program will generate different reports. The application generates the report for users. The admin can view and download the report of the data. The application deliver the excel format reports. Because, excel formatted reports is very easy to understand the income and expense of the college bus. This application is mainly develop for windows operating system users. In 2017, 73% of people enterprises are using windows operating system. So the application will easily install for all the windows operating system users. The application-developed size is very low. The application consumes very low space in disk. Therefore, the user can allocate very minimum local disk space for this application.
Saudi Arabia stands as a titan in the global energy landscape, renowned for its abundant oil and gas resources. It's the largest exporter of petroleum and holds some of the world's most significant reserves. Let's delve into the top 10 oil and gas projects shaping Saudi Arabia's energy future in 2024.
Hybrid optimization of pumped hydro system and solar- Engr. Abdul-Azeez.pdffxintegritypublishin
Advancements in technology unveil a myriad of electrical and electronic breakthroughs geared towards efficiently harnessing limited resources to meet human energy demands. The optimization of hybrid solar PV panels and pumped hydro energy supply systems plays a pivotal role in utilizing natural resources effectively. This initiative not only benefits humanity but also fosters environmental sustainability. The study investigated the design optimization of these hybrid systems, focusing on understanding solar radiation patterns, identifying geographical influences on solar radiation, formulating a mathematical model for system optimization, and determining the optimal configuration of PV panels and pumped hydro storage. Through a comparative analysis approach and eight weeks of data collection, the study addressed key research questions related to solar radiation patterns and optimal system design. The findings highlighted regions with heightened solar radiation levels, showcasing substantial potential for power generation and emphasizing the system's efficiency. Optimizing system design significantly boosted power generation, promoted renewable energy utilization, and enhanced energy storage capacity. The study underscored the benefits of optimizing hybrid solar PV panels and pumped hydro energy supply systems for sustainable energy usage. Optimizing the design of solar PV panels and pumped hydro energy supply systems as examined across diverse climatic conditions in a developing country, not only enhances power generation but also improves the integration of renewable energy sources and boosts energy storage capacities, particularly beneficial for less economically prosperous regions. Additionally, the study provides valuable insights for advancing energy research in economically viable areas. Recommendations included conducting site-specific assessments, utilizing advanced modeling tools, implementing regular maintenance protocols, and enhancing communication among system components.
Final project report on grocery store management system..pdfKamal Acharya
In today’s fast-changing business environment, it’s extremely important to be able to respond to client needs in the most effective and timely manner. If your customers wish to see your business online and have instant access to your products or services.
Online Grocery Store is an e-commerce website, which retails various grocery products. This project allows viewing various products available enables registered users to purchase desired products instantly using Paytm, UPI payment processor (Instant Pay) and also can place order by using Cash on Delivery (Pay Later) option. This project provides an easy access to Administrators and Managers to view orders placed using Pay Later and Instant Pay options.
In order to develop an e-commerce website, a number of Technologies must be studied and understood. These include multi-tiered architecture, server and client-side scripting techniques, implementation technologies, programming language (such as PHP, HTML, CSS, JavaScript) and MySQL relational databases. This is a project with the objective to develop a basic website where a consumer is provided with a shopping cart website and also to know about the technologies used to develop such a website.
This document will discuss each of the underlying technologies to create and implement an e- commerce website.
Introduction to the OMG Systems Modeling Language (SysML), Version 2
1. SST
Tutorial
MODELS Conference
16 October 2020
Ed Seidewitz
Model Driven Solutions, Inc.
ed-s@modeldriven.com
@seidewitz
https://slideshare.net/seidewitz
Introduction to the
OMG Systems Modeling Language™
SysML® Version 2
2. SSTAgenda (1)
I. Introduction
A. Background
B. Language Architecture
C. Pilot Implementation
II. Structural Modeling
A. Packages, Comments and Documentation
B. Parts and Attributes
C. Items
D. Variant Modeling
E. Individuals and Snapshots
F. Connectors, Ports and Interfaces
G. Item Flows
16 October 20202
3. SSTAgenda (2)
III. Behavioral Modeling
A. Actions
B. States and Transitions
C. Expressions and Calculations
D. Constraints
E. Requirements
F. Analysis Cases
G. Other Capabilities
IV. Model Libraries
16 October 20203
5. SSTSystems Modeling Language™ (SysML®)
16 October 2020
SysML v1.0 adopted in 2006
Standard profile of UML v2.1
Current version is SysML v1.6
v1.7 expected to be last for SysML v1
SysML v2 RFPs issue
Language: December 2017
API and Services: June 2018
Supports the specification, analysis, design, and verification and
validation of complex systems that may include hardware, software,
information, processes, personnel, and facilities
5
6. SSTSysML v2 Submission Team (SST)
16 October 2020
A broad team of end users, vendors,
academics, and government liaisons
Currently 100+ members from 70+ organizations
Developing submissions to both RFPs
Driven by RFP requirements and user needs
6
7. SSTSST Participating Organizations
Aerospace Corp
Airbus
ANSYS medini
Aras
Army Aviation & Missile Center
Army CBRND
BAE
BigLever Software
Boeing
Army CCDC Armaments Center
CEA
Contact Software
DEKonsult
Delligatti Associates
Draper Lab
Elbit Systems of America
ESTACA
Ford
Fraunhofer FOKUS
General Motors
George Mason University
GfSE
Georgia Tech/GTRI
IBM
Idaho National Laboratory
16 October 2020
IncQuery Labs
Intercax
Itemis
Jet Propulsion Lab
John Deere
Kenntnis
KTH Royal Institute of Technology
LieberLieber
Lightstreet Consulting
Lockheed Martin
MathWorks
Maplesoft
Mgnite Inc
MITRE
ModelAlchemy Consulting
Model Driven Solutions
Model Foundry
NIST
No Magic/Dassault Systemes
OAR
Obeo
OOSE
Ostfold University College
Phoenix Integration
PTC
Qualtech Systems, Inc (QSI)
Raytheon
Rolls Royce
Saab Aeronautics
SAF Consulting *
SAIC
Siemens
Sierra Nevada Corporation
Simula
Sodius Willert
System Strategy *
Tata Consultancy Services
Thales
Thematix
Tom Sawyer
UFRPE
University of Cantabria
University of Alabama in Huntsville
University of Detroit Mercy
University of Kaiserslautern / VPE
Vera C. Rubin Observatory
Vitech
88solutions
Academia/Research
End User
Tool Vendors
Government Rep
INCOSE rep *
7
8. SSTKey Elements of SysML v2
New Metamodel that is not constrained by UML
Grounded in formal semantics
Robust visualizations based on
flexible view and viewpoint specification
Textual, Graphical, Tabular
Standardized API to access the model
16 October 20208
9. SSTSysML v2 Language Architecture
16 October 20209 Last changed: 2020-09
Root
Syntax
Core
Syntax
Core
Semantics
semantic
specification
Kernel Modeling Language
(KerML)
Direct semantic mapping
to formal logic
Kernel
Syntax
Kernel Model
Library
metamodel
semantic library
Systems
Syntax
Systems and
Domain Model
Libraries
metamodel
semantic library
Systems Modeling Language
(SysML)
Declarative semantic
base elements and
domain-specific libraries
modeled using SysML
Root syntactic elements
without model-level
semantics (e.g., packaging)
Declarative semantic
base elements modeled
using KerML
10. SSTKernel
Syntax and Semantics
16 October 2020
The Root layer
provides the syntactic
foundation for KerML.
The Core layer
provides the semantic
foundation for KerML.
The Kernel layer
completes the KerML
metamodel.
KerML semantics is
ultimately grounded in
first-order logic.
10
Declarative semantic
base elements
modeled using KerML
12. SSTSysML
Syntax and Semantics
16 October 2020
MOF-conformance
abstract syntax model
Based on domain-
independent kernel
abstract syntax.
Domain-specific model
libraries (e.g., Quantities
and Units), written in
SysML.
Declarative semantic
model libraries, written in
SysML.
Based on kernel semantic
model libraries, written in
KerML.
12
13. SSTPilot Implementation
2020-09 release
Publicly available on Google Drive
https://www.openmbee.org/sysml-v2-release/2020-09
Google group for comments and questions
https://groups.google.com/forum/#!forum/sysml-v2-release
(to request membership, provide name, affiliation and interest)
Content available on google drive
Read me file (includes installation instructions)
Specification documents (KerML, SysML, API & Services)
Training material for SysML textual notation
Installation file for Jupyter tooling
Installation site for Eclipse plug-in
Web access to prototype repository via SysML v2 API
Web access to Tom Sawyer visualization tooling
Source code to be available soon on GitHub
16 October 202013
14. SSTPilot Implementation
Eclipse Platform
16 October 202014
Syntax-aware editor for
textual notation.
Linked graphical
visualization based on
(extended) PlantUML.
Future plans:
Prototype graphical
editor using Sirius.
15. SSTPilot Implementation
Jupyter Notebook (1)
16 October 202015
Implementation package
in a Jupyter language
kernel for SysML v2.
…
SysML text can be
edited in a cell, with
syntax highlighting.
Text is parsed and
validated
Future plans: Model
execution/evaluation.
19. SSTPackages – Members
package 'Package Example' {
import ScalarValues::*;
part def Automobile;
alias Automobile as Car;
import ISO::TorqueValue as Torque;
}
A package acts as a namespace
for its members and a container
for its owned members. An import adds all the members
of the imported package to the
importing package.
The owned members of
a package are elements
directly contained in
the package.
A package can introduce aliases
for owned members or individual
members of other packages,
using alias or import keywords.
A name with spaces or other
special characters is
surrounded in singe quotes.
A qualified name is a package name
(which may itself be qualified)
followed by the name of one of its
members, separated by :: .
16 October 202019
20. SSTPackages –Visibility
16 October 2020
package 'Package Example' {
private import ScalarValues::*;
private part def Automobile;
public alias Automobile as Car;
import ISO::TorqueValue as Torque;
}
A private member is
not visible outside the
package (but it is visible
to subpackages).
Members are public by
default but can also be
marked public
explicitly.
All members from a public import
are visible (re-exported) from the
importing package. Members
from a private import are not.
20
21. SSTComments
16 October 2020
package 'Comment Example’ {
/* This is documentary comment, part of the model,
* annotating (by default) it's owning package. */
comment Comment1 /* This is a named comment. */
comment about Automobile
/* This is an unnamed documentary comment,
* annotating an explicitly specified element.
*/
part def Automobile;
/**
* This is a documentary comment, annotating the
* following element.
*/
alias Automobile as Car;
// This is a note. It is in the text, but not part
// of the model.
import ISO::TorqueValue as Torque;
}
A comment begins with /* and
ends with */ .
A note begins with // and
extends to the end of the line.
(A multiline note begins with
//* and ends with */.)
A comment that begins that
with /** annotates the
following element.
A comment can optionally be
named.
What the comment annotates
can be explicitly specified (it is
the owning package by default).
21
22. SSTDocumentation
16 October 2020
package 'Documentation Example' {
doc /* This is documentation of the owning
* package.
*/
part def Automobile {
doc /* This is documentation of Automobile. */
}
alias Automobile as Car;
import ISO::TorqueValue as Torque;
}
Documentation is a special
kind of comment that is
directly owned by the
element it documents.
Alias and import elements
cannot have documentation
comments.
Because it is not a member,
a documentation comment
cannot be named.
22
23. SSTDependencies
16 October 202023
package 'Dependency Example' {
part 'System Assembly' {
part 'Computer Subsystem' {
…
}
part 'Storage Subsystem' {
…
}
}
package 'Software Design' {
item def MessageSchema {
…
}
item def DataSchema {
…
}
}
dependency from 'System Assembly'::'Computer Subsystem' to 'Software Design';
dependency Schemata
from 'System Assembly'::'Storage Subsystem'
to 'Software Design'::MessageSchema, 'Software Design'::DataSchema;
}
A dependency is a relationship that indicates that
one or more client elements require one more
supplier elements for their complete specification.
A dependency is entirely a model-level
relationship, without instance-level semantics.
A dependency can be between any kinds of elements,
generally meaning that a change to a supplier may
necessitate a change to the client element.
A dependency can have multiple clients and/or suppliers.
24. SSTPart and Attribute Definitions
16 October 2020
part def Vehicle {
attribute mass : ScalarValues::Real;
part eng : Engine;
ref part driver : Person;
}
attribute def VehicleStatus {
import ScalarValues::*;
gearSetting : Integer;
acceleratorPosition : Real;
}
part def Engine;
part def Person;
A part definition is a definition of
a class of systems or parts of
systems, which are mutable and
exist in space and time.
An attribute usage is a feature of
a part definition that is a usage
of an attribute definition.
A part usage is a composite
feature that is the usage of a
part definition.
A reference part usage is a
referential feature that is the
usage of a part definition.
An attribute definition is a definition
of attributive data that can be used
to describe systems or parts.
An attribute definition may
not have part usages.
The attribute keyword is
optional on attribute usages.
import works for any nested
packaging.
24
block is a synonym for part def.
value type is a synonym for attribute def.
value is a synonym for attribute.
25. SSTGeneralization/Specialization
16 October 2020
abstract part def Vehicle;
part def HumanDrivenVehicle specializes Vehicle {
ref part driver : Person;
}
part def PoweredVehicle :> Vehicle {
part eng : Engine;
}
part def HumanDrivenPoweredVehicle :>
HumanDrivenVehicle, PoweredVehicle;
part def Engine;
part def Person;
A specialized definition defines
a subset of the classification of
its generalization.
An abstract definition
is one whose instances
must be members of
some specialization.
The :> symbol is equivalent
to the specializes keyword.
A specialization can define
additional features.
A definition can have multiple
generalizations, inheriting the
features of all general definitions.
25
26. SSTSubsetting
16 October 2020
part def Vehicle {
part parts : VehiclePart[*];
part eng : Engine subsets parts;
part trans : Transmission subsets parts;
part wheels : Wheel[4] :> parts;
}
abstract part def VehiclePart;
part def Engine :> VehiclePart;
part def Transmission :> VehiclePart;
part def Wheel :> VehiclePart;
Subsetting asserts that, in any
common context, the values of one
feature are a subset of the values of
another feature.
Subsetting is a kind of
generalization between features.
26
27. SSTRedefinition
16 October 2020
part def Vehicle {
part eng : Engine;
}
part def SmallVehicle :> Vehicle {
part smallEng : SmallEngine redefines eng;
}
part def BigVehicle :> Vehicle {
part bigEng : BigEngine :>> eng;
}
part def Engine {
part cyl : Cylinder[4..6];
}
part def SmallEngine :> Engine {
part redefines cyl[4];
}
part def BigEngine :> Engine {
part redefines cyl[6];
}
part def Cylinder;
A specialized definition can
redefine a feature that would
otherwise be inherited, to change
its name and/or specialize its type.
The :>> symbol is equivalent
to the redefines keyword.
A feature can also specify
multiplicity.
Redefinition can be used to constrain
the multiplicity of a feature.
There is shorthand notation
for redefining a feature with
the same name.
27
28. SSTParts (1)
16 October 2020
// Definitions
part def Vehicle {
part eng : Engine;
}
part def Engine {
part cyl : Cylinder[4..6];
}
part def Cylinder;
// Usages
part smallVehicle : Vehicle {
part redefines eng {
part redefines cyl[4];
}
}
part bigVehicle : Vehicle {
part redefines eng {
part redefines cyl[6];
}
}
Typing is a kind of generalization.
Parts inherit properties from
their definitions and can
redefine them, to any level of
nesting.
Parts can be specified
outside the context of a
specific part definition.
28
29. SSTParts (2)
16 October 2020
// Definitions
part def Vehicle;
part def Engine;
part def Cylinder;
// Usages
part vehicle : Vehicle {
part eng : Engine {
part cyl : Cylinder[4..6];
}
}
part smallVehicle :> vehicle {
part redefines eng {
part redefines cyl[4];
}
}
part bigVehicle :> vehicle {
part redefines eng {
part redefines cyl[6];
}
}
Composite structure can be
specified entirely on parts.
A part can specialize
another part.
29
30. SSTItems
16 October 202030
item def Fuel;
item def Person;
part def Vehicle {
attribute mass : Real;
ref item driver : Person;
part fuelTank {
item fuel: Fuel;
}
}
An item definition defines a class of
things that exist in space and time but
are not necessarily considered "parts"
of a system being modeled.
A system model may reference discrete
items that interact with or pass through
the system.
Items may also model continuous
materials that are stored in and/or flow
between parts of a system.
All parts can be treated as items, but
not all items are parts.The design of a
system determines what should be
modeled as its "parts".
An item is continuous if any portion of it in space is the
same kind of thing. A portion of fuel is still fuel. A portion
of a person is generally no longer a person.
31. SSTVariation Definitions
16 October 202031
attribute def Diameter :> LengthValue;
part def Cylinder {
attribute diameter : Diameter[1];
}
part def Engine {
part cylinder : Cylinder[2..*];
}
part '4cylEngine' : Engine {
part redefines cylinder[4];
}
part '6cylEngine' : Engine {
part redefines cylinder[6];
}
// Variability model
variation attribute def DiameterChoices :> Diameter {
variant attribute diameterSmall = 70@[mm];
variant attribute diameterLarge = 100@[mm];
}
variation part def EngineChoices :> Engine {
variant '4cylEngine';
variant '6cylEngine';
}
Any kind of definition can be
marked as a variation,
expressing variability within a
product line model.
A variation defines one or
more variant usages, which
represent the allowed
choices for that variation.
A variation definition will typically
specialize a definition from a design
model, representing the type of thing
being varied.The variants must then
be valid usages of this type.
Variant definitions can also reference
usages defined elsewhere.
32. SSTVariation Usages
16 October 202032
abstract part vehicleFamily : Vehicle {
part engine : EngineChoices[1];
variation part transmission : Transmission[1] {
variant manualTransmission;
variant automaticTransmission;
}
assert constraint {
(engine == engine::'4cylEngine' &
transmission == transmission::manualTransmission) ^
(engine == engine::'6cylEngine' &
transmission == transmission::automaticTransmission)
}
}
A variation definition can be used
like any other definition, but valid
values of the usage are restricted
to the allowed of the variation.Any kind of usage an also be
a variation, defining
allowable variants without a
separate variation definition.
A constraint can be used to
model restrictions across the
choices that can be made.
The operator & means "and" and the operator ^ means "exclusive or".
So, this constraint means "choose either a 4cylEngine and a
manualTransmission, or a 6cylEngine and an automaticTransmission".
33. SSTVariation Configuration
16 October 202033
part vehicle4Cyl :> vehicleFamily {
part redefines engine = engine::'4cylEngine';
part redefines transmission = transmission::manualTransmission;
}
part vehicle6Cyl :> vehicleFamily {
part redefines engine = engine::'6cylEngine';
part redefines transmission = transmission::manualTransmission;
}
An element from a variability model
with variation usages can be configured
by specializing it and making selections
for each of the variations.
Choosing a manualTransmission with a
6cylEngine is not allowed by the
constraint asserted on vehicleFamily,
so this model of vehicle6Cyl is invalid.
A selection is made for a variation
by binding one of the allowed
variants to the variation usage.
34. SSTIndividuals and Snapshots
16 October 202034
individual def PhysicalContext;
individual def Vehicle_1 :> Vehicle;
individual context : PhysicalContext {
snapshot vehicle_1_t0 : Vehicle_1 {
:>> mass = 2000.0;
:>> status {
:>> gearSetting = 0;
:>> acceleratorPosition = 0.0;
}
}
}
An individual definition is an
item definition restricted to
model a single individual and
how it changes over its lifetime.
An individual usage
represents an
individual during some
portion of its lifetime.
A snapshot is an
individual usage at a
single instant of time.
This is a compact
notation for showing
redefinition of an
attribute usage. An attribute does not have
snapshots, but it can be
asserted to have a specific
value in a certain snapshot.
An individual definition will often
specialize an item or part
definition for the general class of
things the individual is one of.
35. SSTSnapshot Succession
16 October 202035
individual context : PhysicalContext {
snapshot vehicle_1_t0 : Vehicle_1 {
:>> mass = 2000.0;
:>> status {
:>> gearSetting = 0;
:>> acceleratorPosition = 0.0;
}
}
snapshot vehicle_1_t1 : Vehicle_1 {
:>> mass = 1500.0;
:>> status {
:>> gearSetting = 2;
:>> acceleratorPosition = 0.5;
}
}
succession vehicle_1_t0 then vehicle_1_t1;
}
The values of the attributes
of an individual can change
over time.
A succession asserts that
the first snapshot occurs
before the second in time,
in some context.
36. SSTIndividuals and Roles
16 October 202036
individual def Vehicle_1 :> Vehicle {
part leftFrontWheel : Wheel;
part rightFrontWheel : Wheel;
}
individual def Wheel_1 :> Wheel;
individual vehicle_1 : Vehicle_1 {
snapshot vehicle_1_t0 {
snapshot leftFrontWheel_t0 : Wheel_1 :>> leftFrontWheel;
}
then snapshot vehicle_1_t1 {
snapshot rightFrontWheel_t1 : Wheel_1 :>> rightFrontWheel;
}
}
During the first snapshot of
Vehicle_1, Wheel_1 has the
role of the leftFrontWheel.
During a later snapshot, the
sameWheel_1 has the role
of the rightFrontWheel.
By default, these are
snapshots of the
containing individual.
This is a shorthand for a
succession between the
lexically previous snapshot
and this snapshot.
37. SSTIndividuals andTime Slices
16 October 202037
individual def Alice :> Person;
individual def Bob :> Person;
individual : Vehicle_1 {
timeslice aliceDriving {
ref individual :>> driver : Alice;
snapshot :>> start {
:>> mass = 2000.0;
}
snapshot :>> done {
:>> mass = 1500.0;
}
}
then timeslice bobDriving {
ref individual :>> driver : Bob;
}
}
A time slice represents
an individual over
some period of time.
During this time slice of
Vehicle_1, the Alice has
the role of the driver.
start and done are
snapshots at the
beginning and end of
the time slice.
During a latter time slice
ofVehicle_1, Bob has the
role of the driver.
Succession asserts that
the first time slice must
complete before the
second can begin.
Future plans: Provide
time coordinatization for
time slices and snapshots.
38. SSTConnections (1)
16 October 2020
connection def PressureSeat {
end : TireBead[1];
end : TireMountingRim[1];
}
part wheelHubAssembly : WheelHubAssembly {
part wheel : WheelAssembly[1] {
part t : Tire[1] {
part bead : TireBead[2];
}
part w: Wheel[1] {
part rim : TireMountingRim[2];
part mountingHoles : LugBoltMountingHole[5];
}
connection : PressureSeat connect t::bead to w::rim;
}
part lugBoltJoints : LugBoltJoint[0..5];
part hub : Hub[1] {
part h : LugBoltThreadableHole[5];
}
connect lugBoltJoints[0..1]
to mountingHole => wheel::w::mountingHoles[1];
connect lugBoltJoints[0..1]
to threadedHole => hub::h[1];
}
A connection definition is a part
definition whose usages are
connections between its ends.
Connection ends are
reference usages by default
(use part for composition).
A connection is a usage of
an association block that
links to other properties.
If a connection definition
is not specified, a generic
Connection type is used.
38
assoc block is a synonym
for connection def.
link is a synonym for
connection.
39. SSTConnections (2)
16 October 202039
These are owned features of
the part wheel, not the part
definitionWheelAssembly.
Qualifications on names like
wheel::w::mountingHoles in the
textual notation serve the purpose
of property paths in SysML v1.
40. SSTPorts
16 October 2020
port def FuelOutPort {
attribute temperature : Temp;
out item fuelSupply : Fuel;
in item fuelReturn : Fuel;
}
port def FuelInPort {
value temperature : Temp;
in item fuelSupply : Fuel;
out item fuelReturn : Fuel;
}
part def FuelTankAssembly {
port fuelTankPort : FuelOutPort;
}
part def Engine {
port engineFuelPort : FuelInPort;
}
A port definition defines
features that can be
made available via ports.
(Replaces interface
blocks in SysML v1).
Ports may have attribute and
reference features. A feature
with a direction (in, out or
inout) is a flow feature.
A port is a connection point
through which a part
definition exposes some of
its properties in a limited
way. (Like a proxy port in
SysML v1.)
Two ports are compatible
for connection if they have
flows that match with
inverse directions.
40
Flow features are always
referential, so it is not
necessary to explicitly use
the ref keyword.
41. SSTPort Conjugation
16 October 2020
port def FuelPort {
attribute temperature : Temp;
out item fuelSupply : Fuel;
in item fuelReturn : Fuel;
}
part def FuelTankAssembly {
port fuelTankPort : FuelPort;
}
part def Engine {
port engineFuelPort : ~FuelPort;
}
Using a ~ symbol on the port type is a
short had for using the conjugate port
definition (e.g., FuelPort::'~FuelPort').
41
Every port definition has an implicit
conjugate port definition that reverses
input and output flows. It has the
name of the original definition with ~
prepended (e.g., '~FuelPort').
42. SSTInterfaces
16 October 2020
interface def FuelInterface {
end supplierPort : FuelPort;
end consumerPort : ~FuelPort;
}
part vehicle : Vehicle {
part tankAssy : FuelTankAssembly {
port redefines fuelTankPort;
}
part eng : Engine {
port redefines engineFuelPort;
}
interface : FuelInterface connect
supplierPort => tankAssy::fuelTankPort to
consumerPort => eng::engineFuelPort;
}
An interface definition is a
connection definition
whose ends are ports.
An interface usage is a
connection usage defined by
an interface definition,
linking two compatible ports.
Ports need to be
redefined here to
provide local
connection points.
42
43. SST
tankAssy :
FuelTank
Assembly
eng :
Engine
fuelTankPort engineFuelPort
: FuelInterface
vehicle :Vehicle
Local Connection Points
16 October 2020
part vehicle : Vehicle {
part tankAssy : FuelTankAssembly {
port redefines fuelTankPort;
}
part eng : Engine {
port redefines engineFuelPort;
}
interface : FuelInterface connect
supplierPort => tankAssy::fuelTankPort to
consumerPort => eng::engineFuelPort;
}
These ports are actually on the
parts, not the part definitions!
43
44. SSTInterface Decomposition
16 October 2020
interface def WaterDelivery {
end suppliedBy : SpigotBank[1] {
port hot : Spigot;
port cold : Spigot;
}
end deliveredTo : Faucet[1..*] {
port hot : FaucetInlet;
port cold : FaucetInlet;
}
connect suppliedBy::hot to deliveredTo::hot;
connect suppliedBy::cold to deliveredTo::cold;
}
Connection ends have multiplicities
corresponding to navigating across
the connection…
…but they can be interconnected like
participant features.
44
«interface def»
WaterDelivery
hot hot
cold cold
suppliedBy :
SpigotBank[1]
deliveredTo :
Faucet[1..*]
45. SSTBinding Connection (1)
16 October 2020
part tank : FuelTankAssembly {
port redefines fuelTankPort {
out item redefines fuelSupply;
in item redefines fuelReturn;
}
bind fuelTankPort::fuelSupply = pump::pumpOut;
bind fuelTankPort::fuelReturn = tank::fuelIn;
part pump : FuelPump {
out item pumpOut : Fuel;
in item pumpIn : Fuel;
}
part tank : FuelTank {
out item fuelOut : Fuel;
in item fuelIn : Fuel;
}
}
A binding connection is a connection
that asserts the equivalence of the
connected features (i.e., they have
equal values in the same context).
Usages on parts can also have
direction (and are automatically
referential).
45
46. SSTBinding Connections (2)
16 October 2020
part tank : FuelTankAssembly {
port redefines fuelTankPort {
out item redefines fuelSupply;
in item redefines fuelReturn;
}
part pump : FuelPump {
out item pumpOut : Fuel = fuelTankPort::fuelSupply;
in item pumpIn : Fuel;
}
part tank : FuelTank {
out item fuelOut : Fuel;
in item fuelIn : Fuel = fuelTankPort::fuelReturn;
}
}
This shorthand notation combines
the definition of a feature with a
binding connection.
This is not the same as
an initial or default value,
like in UML.
46
47. SSTItem Flows
16 October 2020
tankAssy :
FuelTank
Assembly
eng :
Engine
fuelTankPort engineFuelPort
vehicle :Vehicle
fuelSupply fuelSupply
Fuel
An item flow is streaming if the transfer is ongoing
between the source and target, as opposed to
happening once after the source generates its
output and before the target consumes its input.
47
An item flow is both a
connector between the
source and target ports…
…and a transfer of items
from the source output to
the target input.
48. SSTStreaming Item Flows
16 October 2020
part vehicle : Vehicle {
part tankAssy : FuelTankAssembly {
port redefines fuelTankPort {
out item redefines fuelSupply;
in item redefines fuelReturn;
}
}
part eng : Engine {
port redefines engineFuelPort {
in item redefines fuelSupply;
out item redefines fuelReturn;
}
}
stream of Fuel
from tankAssy::fuelTankPort::fuelSupply
to eng::engineFuelPort::fuelSupply;
stream of Fuel
from eng::engineFuelPort::fuelReturn
to tankAssy::fuelTankPort::fuelReturn;
}
An item flow is a transfer of items
from an output of a source port to
an input of a target port.
Specifying the item type (e.g.,
“of Fuel”) is optional.
48
49. SSTStreaming Interfaces
16 October 2020
interface def FuelInterface {
end supplierPort : FuelOutPort {
out item redefines fuelSupply;
in item redefines fuelReturn;
}
end consumerPort : FuelInPort {
in item redefines fuelSupply;
out item redefines fuelReturn;
}
stream supplierPort::fuelSupply to consumerPort::fuelSupply;
stream consumerPort::fuelReturn to supplierPort::fuelReturn;
}
…
interface : FuelInterface connect
supplierPort => tankAssy::fuelTankPort to
consumerPort => eng::engineFuelPort;
Item flows can be defined
within an interface definition.
The flows are established
when the interface is used.
49
51. SSTAction Definitions (1)
16 October 2020
action def Focus(in scene : Scene, out image : Image);
action def Shoot(in image : Image, out picture : Picture);
action def TakePicture
(in scene : Scene,
out picture : Picture) {
bind focus::scene = scene;
action focus : Focus (in scene, out image);
flow focus::image to shoot::image;
action shoot : Shoot (in image, out picture);
bind shoot::picture = picture;
}
An action definition is a definition
of some action to be performed.
Action definitions may have in, out and
inout parameters (the default is in).
An action is a usage of an
action definition performed
in a specific context.
An action has parameters
corresponding to its action
definition.
An item flow can be
used to transfer items
between actions.
The use of a non-streaming flow means that focus
must finish producing its output before shoot can
begin consuming it. (Streaming can also be used.)
scene
scene
image
image
picture
picture
focus
shoot
TakePicture
51
activity is a synonym
for action def.
52. SSTAction Definitions (2)
16 October 2020
action def Focus(in scene : Scene, out image : Image);
action def Shoot(in image : Image, out picture : Picture);
action def TakePicture {
in item scene : Scene;
out item picture : Picture;
action focus : Focus {
in item scene = TakePicture::scene;
out item image;
}
action shoot : Shoot {
in item image flow from focus::image;
out item picture = TakePicture::picture;
}
} This is the same shorthand
for binding used previously.
This is a shorthand for an
item flow into the parameter.
scene
scene
image
image
picture
picture
focus
shoot
TakePicture
52
Parameters can also be declared in the
action body, similarly to flow features.
53. SSTAction Decomposition
16 October 2020
action def Focus(in scene : Scene, out image : Image);
action def Shoot(in image : Image, out picture : Picture);
action def TakePicture(in scene : Scene, out picture : Picture);
action takePicture : TakePicture {
in item scene;
out item picture;
action focus : Focus {
in item scene = takePicture::scene;
out item image;
}
action shoot : Shoot {
in item image flow from focus::image;
out item picture = takePicture::picture;
}
}
An action can also be
directly decomposed
into other actions.
This is just a composite structure as before, only typed by action definitions
instead of part definitions. (SysML v1 “adjunct properties” are not needed.)
scene
scene
image
image
picture
picture
focus
shoot
takePicture :TakePicture
53
54. SSTAction Succession (1)
16 October 2020
action takePicture : TakePicture {
in item scene;
out item picture;
action focus : Focus {
in item scene = takePicture::scene;
out item image;
}
succession focus then shoot;
action shoot : Shoot {
in item image stream from focus::image;
out item picture = takePicture::picture;
}
}
A succession asserts that the
first action must complete
before the second can begin.
With the succession modeled
explicitly, a stream item flow
can be used here.
scene
scene
image
image
picture
picture
focus
shoot
takePicture :TakePicture
«stream»
54
55. SST
scene
scene
image
image
picture
picture
focus
shoot
takePicture :TakePicture
«stream»
Action Succession (2)
16 October 2020
action takePicture : TakePicture {
in item scene;
out item picture;
action focus : Focus {
in item scene = takePicture::scene;
out item image;
}
then action shoot : Shoot {
in item image stream from focus::image;
out item picture = takePicture::picture;
}
}
This is a shorthand for a succession between
the lexically previous action and this action.
55
56. SSTConditional Succession (1)
16 October 2020
action takePicture : TakePicture {
in item scene;
out item picture;
action focus : Focus {
in item scene = takePicture::scene;
out item image;
}
succession focus
if focus::image::isFocused then shoot;
action shoot : Shoot {
in item image stream from focus::image;
out item picture = takePicture::picture;
}
}
A conditional succession asserts that the
second action must follow the first only
if a guard condition is true. If the guard
is false, succession is not possible.
56
[image::
isFocused]
scene
scene
image
image
picture
picture
focus
shoot
takePicture :TakePicture
«stream»
57. SSTConditional Succession (2)
16 October 2020
action takePicture : TakePicture {
in item scene;
out item picture;
action focus : Focus {
in item scene = takePicture::scene;
out item image;
}
if focus::image::isFocused then shoot;
action shoot : Shoot {
in item image stream from focus::image;
out item picture = takePicture::picture;
}
}
This is a shorthand for a conditional succession
following the lexically previous action.
57
[image::
isFocused]
scene
scene
image
image
picture
picture
focus
shoot
takePicture :TakePicture
«stream»
Note that, currently,
the target action must
be explicitly named.
58. SSTSignaling
16 October 2020
action takePicture : TakePicture {
action trigger accept scene : Scene;
then action focus : Focus {
in item scene = trigger::scene;
out item image;
}
then action shoot : Shoot {
in item image stream from focus::image;
out item picture;
}
then send shoot::picture to display;
}
An accept action receives
an incoming asynchronous
transfer of items.
A send action is an outgoing
transfer of items to a
specific target.
scene
scene
image
image
picture
picture
trigger
focus
display
shoot
«stream»
58
This is the name
of the action This is a declaration of what is being
received, which can be anything.
This is an expression
evaluating to the
item to be sent.
59. SSTMerge Nodes
16 October 2020
action takePicture : TakePicture {
first start;
then merge continue;
then action trigger accept scene : Scene;
then action focus : Focus {
in item scene = trigger::scene;
out item image;
}
then action shoot : Shoot {
in image stream from focus::image;
out picture;
}
then send shoot::picture to display;
then continue;
}
References the start of
the action as the source
of the initial succession.
A merge node waits for exactly
one predecessor to happen
before continuing.
References the merge node named
“continue” as the target of the
succession.
continue
scene
scene
image
image
picture
picture
trigger
focus
display
shoot
«stream»
59
60. SSTDecision Nodes
16 October 2020
action def ChargeBattery {
first start;
then merge continueCharging;
then action monitor
accept batteryCharge : Real;
then decide;
if monitor::batteryCharge < 100 then addCharge;
if monitor::batteryCharge >= 100 then signalCharged;
action addCharge : AddCharge (batteryCharge);
then continueCharging;
send signalCharged
of BatteryCharged()
to powerSystem;
then done;
}
monitor
addCharge
signalCharged
continueCharging
[batteryCharge < 100]
[batteryCharge >= 100]
A decision node is typically followed
by one or more conditional
successions (the last “if…then” can
be replaced by “else”).
The notation “BatteryCharged()” means to
create an instance of the type BatteryCharged to
send as a signal to powerSystem.
References the end of the action
as the target of a succession.
60
A decision node (decide
keyword) chooses exactly one
successor to happen after it.
61. SSTFork and Join Nodes
16 October 2020
action def Brake {
accept TurnKeyToOn;
then fork;
then monitorBrakePedal;
then monitorTraction;
then braking;
action monitorBrakePedal : MonitorBrakePedal (
out brakePressure);
then joinNode;
action monitorTraction : MonitorTraction (
out modulationFrequency);
then joinNode;
action braking : Braking (
in stream from monitorBrakePedal::brakePressure,
in stream from monitorTraction::modulationFrequency);
then joinNode;
join joinNode;
then done;
}
TurnKeyOn
monitor
BrakePedal
monitor
Traction
«stream»
braking
«stream»
A fork node enables all its
successors to happen after it.
A join node waits for all its predecessors
to happen before continuing.
The source for all these
successions is the fork node.
61
62. SSTOpaque Actions
16 October 202062
action def UpdateSensors (in sensors : Sensor[*]) {
language "Alf"
/*
* for (sensor in sensors) {
* if (sensor.ready) {
* Update(sensor);
* }
* }
*/
}
An "opaque" action definition or
usage can be specified using a
textual representation annotation
in a language other than SysML.
The textual representation body is written
using comment syntax.The /*, */ and leading
* symbols are not included in the body text.
Note that support for referencing SysML
elements from the body text is tool-specific.
A textual representation annotation can actually be used with any kind of
element, not just actions. OMG-standard languages a tool may support include
"OCL" (Object Constraint Language) and "Alf" (Action Language for fUML).A tool
can also provide support for other languages (e.g., "JavaScript" or "Modelica").
63. SSTAction Allocation
16 October 2020
part camera : Camera {
port cameraPort {
in item scene = takePhoto::scene;
out item picture = takePhoto::picture;
}
perform action takePhoto[*] ordered
:> takePicture (in scene, out picture);
part f : AutoFocus {
perform takePhoto::focus;
}
part i : Imager {
perform takePhoto::shoot;
}
}
63
perform identifies the
owner as the performer
of an action.
This shorthand simply
identifies the performed
action owned elsewhere
without renaming it locally.
Flow features in ports
can be bound to action
parameters.
64. SSTState Definitions (1)
16 October 202064
state def VehicleStates {
entry; then off;
state off;
transition off_to_starting
first off
accept VehicleStartSignal
then starting;
state starting;
transition starting_to_on
first starting
accept VehicleOnSignal
then on;
state on;
transition on_to_off
first on
accept VehicleOffSignal
then off;
}
off
starting
on
VehicleOnSignal
VehicleStartSignal
VehicleOffSignal
A state definition is like a state machine in
UML and SysML v1. It defines a behavioral
state that can be exhibited by a system.
This indicates the the initial
state after entry is ”off”.
A state definition can specify a
set of discrete nested states.
States are connected by
transitions that fire on
acceptance of item transfers
(like accept actions).
65. SSTState Definitions (2)
16 October 202065
state def VehicleStates {
entry; then off;
state off;
accept VehicleStartSignal
then starting;
state starting;
accept VehicleOnSignal
then on;
state on;
accept VehicleOffSignal
then off;
}
off
starting
on
VehicleOnSignal
VehicleStartSignal
VehicleOffSignal
This is a shorthand for a
transition whose source is
the lexically previous state.
66. SSTState Decomposition
16 October 202066
state def VehicleStates;
state vehicleStates : VehicleStates {
entry; then off;
state off;
accept VehicleStartSignal
then starting;
state starting;
accept VehicleOnSignal
then on;
state on;
accept VehicleOffSignal
then off;
}
A state can be explicitly
declared to be a usage
of a state definition.
A state can also be
directly decomposed
into other states.
off
starting
on
VehicleOnSignal
VehicleStartSignal
VehicleOffSignal
vehicleStates :VehicleStates
This is just a part structure as before, only typed
by state definitions instead of part definitions.
67. SSTConcurrent States
16 October 202067
state def VehicleStates;
state vehicleStates : VehicleStates {
state operationalStates {
entry; then off;
state off;
accept VehicleStartSignal
then starting;
state starting;
accept VehicleOnSignal
then on;
state on;
accept VehicleOffSignal
then off;
}
state healthStates {
…
}
}
If no initial state is specified,
then nested states are
presumed to be concurrent.
off
starting
on
VehicleOnSignal
VehicleStartSignal
VehicleOffSignal
vehicleStates :VehicleStates
operationalStates
healthStates
…
68. SSTState Entry, Do and Exit Actions
16 October 202068
action performSelfTest(vehicle : Vehicle);
state def VehicleStates(operatingVehicle : Vehicle);
state vehicleStates : VehicleStates
(operatingVehicle : Vehicle) {
entry; then off;
state off;
accept VehicleStartSignal
then starting;
state starting;
accept VehicleOnSignal
then on;
state on {
entry performSelfTest
(in vehicle = operatingVehicle);
do action providePower { … }
exit action applyParkingBrake { … }
}
accept VehicleOffSignal
then off;
}
off
starting
VehicleOffSignal
vehicleStates :VehicleStates
on
entry/performSelfTest
do/ providePower
exit/applyParkingBrake
A state entry, do or exit
can reference an action
defined elsewhere…
… or can the action can be
defined within the state.
States, like
actions, can have
parameters.
Entry, do and exit
actions come before
nested states and
transitions.
An entry action is performed on entry
to a state, a do action while in it, and
an exit action on exit from it.
VehicleOnSignal
VehicleStartSignal
69. SSTTransition Guards and Effect Actions
16 October 202069
action performSelfTest(vehicle : Vehicle);
state def VehicleStates(operatingVehicle : Vehicle);
state vehicleStates : VehicleStates (
operatingVehicle : Vehicle,
controller : VehicleController) {
entry; then off;
state off;
accept VehicleStartSignal
then starting;
state starting;
accept VehicleOnSignal
if operatingVehicle::brakePedalDepressed
do send ControllerStartSignal() to controller
then on;
state on { … }
accept VehicleOffSignal
then off;
}
off
starting
on
VehicleOnSignal
VehicleStartSignal
[brakePedalDepressed]/
send ControllerStartSignal()
VehicleOffSignal
vehicleStates :VehicleStates
A guard is a condition
that must be true for a
transition to fire.
An effect action is performed
when a transition fires, before
entry to the target state.
70. SSTState Allocation
16 October 202070
part vehicle : Vehicle {
part vehicleController : VehicleController;
exhibit vehicleStates (
operatingVehicle = vehicle,
controller = vehicleController
);
}
exhibit identifies the part
that is exhibiting states that
are defined elsewhere.
Parameters for a state usage can
be bound in the same way as
parameters of an action usage.
71. SSTExpressions
Mass Rollup Example (1)
16 October 2020
package MassRollup {
import ScalarFunctions::*;
part def MassedThing {
attribute mass subsets ISQ::mass;
attribute totalMass subsets ISQ::mass;
}
part simpleThing : MassedThing {
attribute redefines totalMass = mass;
}
part compositeThing : MassedThing {
part subcomponents: MassedThing[*];
attribute redefines totalMass =
mass + sum(subcomponents->collect p:MassedThing (p::totalMass));
}
}
From the International
System of Quantities
library model.
Alf-based expression
language.
71
Eventually, the shorthand notation
subcomponents.totalMass will be usable
instead of explicit collect (like in OCL).
72. SSTExpressions
Mass Rollup Example (2)
16 October 2020
import ScalarValues::*;
import MassRollup::*;
part def CarPart :> MassedThing {
attribute serialNumber : String;
}
part car: CarPart :> compositeThing {
attribute vin redefines serialNumber;
part carParts : CarPart[*] redefines subcomponents;
part engine :> simpleThing subsets carParts { … }
part transmission :> simpleThing subsets carParts { … }
}
// Example usage
import SI::*;
part c :> car {
redefines car::mass = 1000@[kg];
part redefines engine {
redefines engine::mass = 100@[kg];
}
part redefines transmission {
redefines transmission::mass = 50@[kg];
}
}
// c.totalMass --> 1150.0@[kg]
Units are identified on
the value, not the type.
72
73. SSTCalculation Definitions
16 October 202073
calc def Power (
whlpwr : PowerValue,
Cd : Real,
Cf : Real,
tm : MassValue,
v : VelocityValue ) : PowerValue {
attribute drag = Cd * v;
attribute friction = Cf * tm * v;
whlpwr - drag - friction
}
calc def Acceleration (tp: PowerValue, tm : MassValue, v: VelocityValue) : AccelerationValue {
tp / (tm * v)
}
calc def Velocity (dt : TimeValue, v0 : VelocityValue, a : AccelValue) : VelocityValue
= v0 + a * dt;
calc def Position (dt : TimeValue, x0 : LengthValue, v : VelocityValue) : LengthValue
= x0 + v * dt;
A calculation definition is a reusable,
parameterized expression.
Calculation parameters are similar
to the parameters on actions.
The calculation can include the
computation of intermediate values.
A calculation has a
single return result.
The calculation result expression must
conform to the return type.
There is no semicolon
at the end of a result
expression.
If there are no intermediate computations,
a shortened form can be used.
74. SSTCalculation Usages (1)
16 October 202074
part def VehicleDynamics {
attribute C_d : Real;
attribute C_f : Real;
attribute wheelPower : PowerValue;
attribute mass : MassValue;
action straightLineDynamics(
in delta_t : TimeValue,
in v_in : VelocityValue, in x_in : LengthValue,
out v_out : VelocityValue, out x_out : LengthValue) {
calc acc : Acceleration (
dt = delta_t,
tm = mass,
tp = Power(wheelPower, C_d, C_f, mass, v_in)
) return a;
calc vel : Velocity (
dt = delta_t,
v0 = v_in,
a = acc::a
) return v = v_out;
calc pos : Position (
dt = delta_t,
x0 = x_in,
v0 = vel::v
) return x = x_out;
}
}
Values are bound to the
parameters of calculation usages
(similar to action parameters).
A calculation definition can also be
invoked as an expression, with input
values given as arguments, evaluating
to the result of the calculation.
Note that the return
result is outside the
parentheses.The return
keyword is optional.
Calculation results can be
referenced by name and/or bound
(like action output parameters).
75. SSTCalculation Usages (2)
16 October 202075
attribute def DynamicState {
attribute v: VelocityValue;
attribute x: LengthValue;
}
part def VehicleDynamics {
attribute C_d : Real;
attribute C_f : Real;
attribute wheelPower : PowerValue;
attribute mass : MassValue;
calc updateState
(delta_t : TimeValue, currState : DynamicState) {
attribute totalPower : PowerValue = Power(wheelPower, C_d, C_f, mass, currState::v);
return attribute newState : DynamicState {
:>> v = Velocity(delta_t, currState::v, Acceleration(delta_t, mass, totalPower));
:>> x = Position(delta_t, currState::x, currState::v);
}
}
}
A calculation can be
specified without an explicit
calculation definition. Calculations can also
handle structured values.
This is a declaration of the result parameter of
the calculation, with bound subattributes.
76. SSTConstraint Definitions (1)
16 October 202076
import ISQ::*;
import SI::*;
import ScalarFunctions::*;
constraint def MassConstraint (
partMasses : MassValue[0..*],
massLimit : MassValue) {
sum(partMasses) <= massLimit
}
part def Vehicle {
constraint massConstraint : MassConstraint (
partMasses = {chassisMass, engine::mass, transmission::mass},
massLimit = 2500@[kg]);
attribute chassisMass : MassValue;
part engine : Engine {
attribute mass : MassValue;
}
part transmission : Engine {
attribute mass : MassValue;
}
}
A constraint definition is a reusable,
parameterized Boolean expression.
Constraint parameters are similar
to the parameters on actions.
The constraint expression can be
any Boolean expression using
the constraint parameters.
There is no semicolon
at the end of a
constraint expression.
A constraint is the usage
of a constraint definition,
which may be true or
false in a given context.
A constraint may be
violated (false) without
making the model
inconsistent.
Values are bound to
constraint parameters
(similarly to actions).
77. SSTConstraint Definitions (2)
16 October 202077
import ISQ::*;
import SI::*;
import ScalarFunctions::*;
constraint def MassConstraint {
attribute partMasses : MassValue[0..*];
attribute massLimit : MassValue;
sum(partMasses) <= massLimit
}
part def Vehicle {
constraint massConstraint : MassConstraint {
redefines partMasses = {chassisMass, engine::mass, transmission::mass};
redefines massLimit = 2500@[kg];
}
attribute chassisMass : MassValue;
part engine : Engine {
attribute mass : MassValue;
}
part transmission : Engine {
attribute mass : MassValue;
}
}
Alternatively, constraint
parameters may be modeled as
value or reference properties.
The constraint parameter
properties are then redefined
in order to be bound.
78. SSTConstraint Assertions (1)
16 October 202078
import ISQ::*;
import SI::*;
import ScalarFunctions::*;
constraint def MassConstraint (
partMasses : MassValue[0..*],
massLimit : MassValue) {
sum(partMasses) <= massLimit
}
part def Vehicle {
assert constraint massConstraint : MassConstraint (
partMasses = {chassisMass, engine::mass, transmission::mass},
massLimit = 2500@[kg]);
attribute chassisMass : MassValue;
part engine : Engine {
attribute mass : MassValue;
}
part transmission : Engine {
attribute mass : MassValue;
}
}
A constraint assertion
asserts that a constraint
must be true.
If an assertion is
violated, then the
model is inconsistent.
79. SSTConstraint Assertions (2)
16 October 202079
constraint def MassConstraint (
partMasses : MassValue[0..*],
massLimit : MassValue);
constraint massConstraint : MassConstraint (
partMasses : MassValue[0..*],
massLimit : MassValue) {
sum(partMasses) <= massLimit
}
part def Vehicle {
assert massConstraint (
partMasses = {chassisMass, engine::mass, transmission::mass},
massLimit = 2500@[kg]);
attribute chassisMass : MassValue;
attribute engine : Engine {
value mass : MassValue;
}
attribute transmission : Engine {
value mass : MassValue;
}
}
The constraint expression
can also be defined on a
usage of a constraint def.
A named constraint
can be asserted in
multiple contexts.
80. SSTDerivation Constraints
16 October 202080
part vehicle1 : Vehicle {
attribute totalMass : MassValue;
assert constraint {totalMass == chassisMass + engine::mass + transmission::mass}
}
part vehicle2 : Vehicle {
attribute totalMass : MassValue = chassisMass + engine::mass + transmission::mass;
}
constraint def AveragedDynamics (
mass: MassValue,
initialSpeed : SpeedValue,
finalSpeed : SpeedValue,
deltaT : TimeValue,
force : ForceValue ) {
force * deltaT == mass * (finalSpeed - initialSpeed) &
mass > 0@[kg]
}
In UML and SysML v1, constraints are
often used to defined derived values.
In SysML v2 this can usually be
done more directly using a binding.
However, constraints
allow for more general
equalities and inequalities
than direct derivation.
Be careful about the
difference between ==,
which is the Boolean-valued
equality operator, and =,
which denotes binding.
81. SSTAnalytical Constraints
16 October 202081
constraint def StraightLineDynamicsEquations(
p : PowerValue, m : MassValue, dt : TimeValue,
x_i : LengthValue, v_i : VelocityValue,
x_f : LengthValue, v_f : VelocityValue,
a : AccelerationValue
) {
attribute v_avg : VelocityValue = (v_i + v_f)/2;
a == Acceleration(p, m, v_avg) &
v_f == Velocity(dt, v_i, a) &
x_f == Position(dt, x_i, v_avg)
}
action def StraightLineDynamics (
in power : PowerValue, in mass : MassValue, in delta_t : TimeValue,
in x_in : LengthValue, in v_in : VelocityValue,
out x_out : LengthValue, out v_out : VelocityValue,
out a_out : AccelerationValue
) {
assert constraint dynamics : StraightLineDynamicsEquations (
p = power, m = mass, dt = delta_t,
x_i = x_in, v_i = v_in,
x_f = x_out, v_f = v_out,
a = a_out
);
}
An action definition is inherently
"causal" in the sense that outputs
are determined in terms of inputs.
A constraint is inherently
"acausal" – it is simply true
or false for given values of
its parameters.
Note the use of the
calculation definitions
defined earlier.
This constraint definition
provides a reusable
specification of a system
of (coupled) equations.
This specifies that the action outputs
must be solved for analytically given
the action inputs, consistent with
the asserted constraint.
82. SSTRequirement Definitions (1)
16 October 202082
requirement def MassLimitationRequirement {
doc /* The actual mass shall be less than or equal
* to the required mass. */
attribute massActual : MassValue;
attribute massReqd : MassValue;
require constraint { massActual <= massReqd }
}
A requirement definition is a special
kind of constraint definition.
A textual statement of the requirement can
be given as a documentation comment in
the requirement definition body.
The requirement can be
formalized by giving one or
more component required
constraints.
Like a constraint definition,
a requirement definition
can be parameterized
using features.
83. SSTRequirement Definitions (2)
16 October 202083
part def Vehicle {
attribute dryMass: MassValue;
attribute fuelMass: MassValue;
attribute fuelFullMass: MassValue;
…
}
requirement def id '1' VehicleMassLimitationRequirement :> MassLimitationRequirement {
doc /* The total mass of a vehicle shall be less than or equal to the required mass. */
subject vehicle : Vehicle;
attribute redefines massActual = vehicle::dryMass + vehicle::fuelMass;
assume constraint { vehicle::fuelMass > 0@[kg] }
}
Features of the subject
can be used in the
requirement definition.
A requirement definition is always about some
subject, which may be implicit or specified explicitly.
A requirement definition may also
specify one or more assumptions.
A requirement definition may have a
modeler specified human id, which is
an alternate name for it.
84. SSTRequirement Definitions (3)
16 October 202084
port def ClutchPort;
action def GenerateTorque;
requirement def id '2' DrivePowerInterfaceRequirement {
doc /* The engine shall transfer its generated torque to the transmission
* via the clutch interface. */
subject clutchPort: ClutchPort;
}
requirement def id '3' TorqueGenerationRequirement {
doc /* The engine shall generate torque as a function of RPM as shown in Table 1. */
subject generateTorque: GenerateTorque;
}
The subject of a requirement definition
can have any kind of definition.
85. SSTRequirement Usages
16 October 202085
requirement id '1.1' fullVehicleMassLimit : VehicleMassLimitationRequirement {
subject vehicle : Vehicle;
attribute :>> massReqd = 2000@[kg];
assume constraint {
doc /* Fuel tank is full. */
vehicle::fuelMass == vehicle::fuelFullMass
}
}
requirement id '1.2' emptyVehicleMassLimit : VehicleMassLimitationRequirement {
subject vehicle : Vehicle;
attribute :>> massReqd = 1500@[kg];
assume constraint {
doc /* Fuel tank is empty. */
vehicle::fuelMass == 0@[kg]
}
}
A requirement is the usage of a
requirement definition.
A requirement will often bind
requirement definition
parameters to specific values.
A requirement may optionally
have its own human ID.
86. SSTRequirement Groups
16 October 202086
requirement vehicleSpecification {
doc /* Overall vehicle requirements group */
subject vehicle : Vehicle;
require fullVehicleMassLimit;
require emptyVehicleMassLimit;
}
part def Engine {
port clutchPort: ClutchPort;
perform action generateTorque: GenerateTorque;
}
requirement engineSpecification {
doc /* Engine power requirements group */
subject engine : Engine;
requirement drivePowerInterface : DrivePowerInterfaceRequirement {
subject clutchPort = engine::clutchPort;
}
requirement torqueGeneration : TorqueGenerationRequirement {
subject generateTorque = engine::generateTorque;
}
}
A requirement may also be used
to group other requirements.
Requirements can be
grouped by reference…
…or by composition.
By default, the subject of grouped
requirements is assumed to be the
same as that of the group.
The subject of a grouped
requirement can also be
bound explicitly.
Grouped requirements are treated as
required constraints of the group.
87. SSTRequirement Satisfaction
16 October 202087
part vehicle_c1 : Vehicle {
part engine_v1: Engine { … }
…
}
part 'Vehicle c1 Design Context' {
ref vehicle_design :> vehicle_c1;
satisfy vehicleSpecification by vehicle_design;
satisfy engineSpecification by vehicle_design::engine_v1;
}
Formally, a requirement is satisfied for a subject
if, when all its assumed constraints are true, then
all its required constraints are true.
A requirement satisfaction asserts
that a given requirement is satisfied
when its subject parameter is
bound to a specific thing.
88. SSTAnalysis Case Definitions (1)
16 October 202088
analysis def FuelEconomyAnalysis {
subject vehicle : Vehicle;
return fuelEconomyResult : DistancePerVolumeValue;
objective fuelEconomyAnalysisObjective {
doc /*
* The objective of this analysis is to determine whether the
* subject vehicle can satisfy the fuel economy requirement.
*/
assume constraint {
vehicle::wheelDiameter == 33@['in'] &
vehicle::driveTrainEfficiency == 0.4
}
require constraint {
fuelEconomyResult > 30@[mi / gallon]
}
}
…
}
An analysis case definition defines the
computation of the result of analyzing
some subject, meeting an objective.
The subject may be specified similarly to
the subject of a requirement definition).
The analysis result is declared as a return
result (as for a calculation definition).
The analysis objective is specified as a
requirement, allowing both assumed
and required constraints.
The objective is a requirement on
the result of the analysis case.
89. SSTAnalysis Case Definitions (2)
16 October 202089
analysis def FuelEconomyAnalysis {
subject vehicle : Vehicle;
return fuelEconomyResult : DistancePerVolumeValue;
…
in attribute scenario[*] {
time : TimeValue;
position : LengthValue;
velocity : VelocityValue;
}
action solveForPower {
out power: PowerValue[*];
out acceleration: AccelerationValue[*];
assert constraint {
{1..size(scenario)-1}->forAll i (
StraightLineDynamicsEquations (
power[i], vehicle::mass,
scenario::time[i+1] - scenario::time[i],
scenario::position[i], scenario::velocity[i],
scenario::position[i+1], scenario::velocity[i+1],
acceleration[i+1]))
}
}
then action solveForFuelEconomy {
in power : PowerValue[*] = solveForPower::power;
out fuelEconomy : DistancePerVolumeValue = fuelEconomyResult;
… }
}
The steps of an analysis case
are actions that, together,
compute the analysis result. The first step solves for the
engine power needed for a
given position/velocity scenario.
The second step computes the fuel
economy result, given the power
profile determined in the first step.
Additional parameters can be
specified in the case body.
90. SSTAnalysis Case Usages
16 October 202090
part vehicleFuelEconomyAnalysisContext {
requirement vehicleFuelEconomyRequirements{subject vehicle : Vehicle; … }
attribute cityScenario :> FuelEconomyAnalysis::scenario = { … };
attribute highwayScenario :> FuelEconomyAnalysis::scenario = { … };
analysis cityAnalysis : FuelEconomyAnalysis {
subject vehicle = vehicle_c1;
in scenario = cityScenario;
}
analysis highwayAnalysis : FuelEconomyAnalysis {
subject vehicle = vehicle_c1;
in scenario = highwayScenario;
}
part vehicle_c1 : Vehicle {
…
attribute :>> fuelEconomy_city = cityAnalysis::fuelEconomyResult;
attribute :>> fuelEconomy_highway = highwayAnalysis::fuelEconomyResult;
}
satisfy vehicleFuelEconomyRequirements by vehicle_c1;
}
The previously defined analysis is carried
out for a specific vehicle configuration
for two different scenarios.
If the vehicle fuel economy is set to
the results of the analysis, then this
configuration is asserted to satisfy the
desired fuel economy requirements.
The subject and parameters are
automatically redefined, so redefinition
does not need to be specified explicitly.
91. SSTOther Capabilities
(Under Development)
Trade-off Analysis
A trade-off analysis uses analysis cases to evaluate alternative
designs based on a set of criteria and selecting a preferred design
Verification Cases
A verification case is a case whose objective is to verify that a
subject satisfies its requirements
Views and Viewpoints
A view specifies a rendering of some portion of a model to satisfy
the viewpoint of one or more stakeholders.
Language Extension
A language extension builds new user-defined capabilities on
SysML, in the same way that SysML builds on KerML.
16 October 202091
94. SSTKernel
Base Functions
16 October 2020
package BaseFunctions {
import Base::*;
import ScalarValues::*;
function '=='(x: Anything, y: Anything): Boolean;
function '!='(x: Anything, y: Anything): Boolean;
function ToString(x: Anything): String;
function size(seq: Anything[*]): Natural;
function isEmpty(seq: Anything[*]): Boolean;
function notEmpty(seq: Anything[0..*]): Boolean;
function head(seq: Anything[0..*]): Boolean;
function tail(seq: Anything[0..*]): Boolean;
function last(seq: Anything[0..*]): Boolean;
…
}
94
95. SSTKernel
Scalar Functions
16 October 2020
package ScalarFunctions {
import ScalarValues::*;
abstract function '+'(x: ScalarValue, y: ScalarValue[0..1]): ScalarValue;
abstract function '-'(x: ScalarValue, y: ScalarValue[0..1]): ScalarValue;
abstract function '*'(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '/'(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '**'(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '%'(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '!'(x: ScalarValue): ScalarValue;
abstract function '~'(x: ScalarValue): ScalarValue;
abstract function '|'(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '^'(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '&'(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '<'(x: ScalarValue, y: ScalarValue): Boolean;
abstract function '>'(x: ScalarValue, y: ScalarValue): Boolean;
abstract function '<='(x: ScalarValue, y: ScalarValue): Boolean;
abstract function '>='(x: ScalarValue, y: ScalarValue): Boolean;
abstract function Max(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function Min(x: ScalarValue, y: ScalarValue): ScalarValue;
abstract function '@'(x: ScalarValue, y: Base::Anything): ScalarValue;
abstract function '..'(lower: ScalarValue, upper: ScalarValue):ScalarValue[0..*];
abstract function sum(collection: ScalarValue[0..*]): ScalarValue;
abstract function product(collection: ScalarValue[0..*]);
}
95
96. SSTKernel
Boolean Functions
16 October 202096
package BooleanFunctions {
import ScalarValues::*;
function '!' specializes ScalarFunctions::'!'(x: Boolean): Boolean;
function '|' specializes ScalarFunctions::'|'(x: Boolean, y: Boolean): Boolean;
function '^' specializes ScalarFunctions::'^'(x: Boolean, y: Boolean): Boolean;
function '&' specializes ScalarFunctions::'&'(x: Boolean, y: Boolean): Boolean;
function '==' specializes BaseFunctions::'=='(x: Boolean, y: Boolean): Boolean;
function '!=' specializes BaseFunctions::'!='(x: Boolean, y: Boolean): Boolean;
function ToString specializes BaseFunctions::ToString (x: Boolean): String;
function ToBoolean(x: String): Boolean;
}
97. SSTKernel
String Functions
16 October 202097
package StringFunctions {
import ScalarValues::*;
function '+' specializes ScalarFunctions::'+'(x: String, y:String): String;
function Size(x: String): Natural;
function Substring(x: String, lower: Integer, upper: Integer): String;
function '<' specializes ScalarFunctions::'<'(x: String, y: String): Boolean;
function '>' specializes ScalarFunctions::'>'(x: String, y: String): Boolean;
function '<=' specializes ScalarFunctions::'<='(x: String, y: String): Boolean;
function '>=' specializes ScalarFunctions::'>='(x: String, y: String): Boolean;
function '=' specializes BaseFunctions::'=='(x: String, y: String): Boolean;
function '!=' specializes BaseFunctions::'!='(x: String, y: String): Boolean;
function ToString specializes BaseFunctions::ToString(x: String): String;
}
98. SSTKernel
Integer Functions
16 October 202098
package IntegerFunctions {
import ScalarValues::*;
function Abs specializes NumericalFunctions::Abs (x: Integer): Natural;
function '+' specializes NumericalFunctions::'+' (x: Integer, y: Integer[0..1]): Integer;
function '-' specializes NumericalFunctions::'-' (x: Integer, y: Integer[0..1]): Integer;
function '*' specializes NumericalFunctions::'*' (x: Integer, y: Integer): Integer;
function '/' specializes NumericalFunctions::'/' (x: Integer, y: Integer): Integer;
function '**' specializes NumericalFunctions::'**' (x: Integer, y: Natural): Integer;
function '%' specializes NumericalFunctions::'%' (x: Integer, y: Integer): Integer;
function '<' specializes NumericalFunctions::'<' (x: Integer, y: Integer): Boolean;
function '>' specializes NumericalFunctions::'>' (x: Integer, y: Integer): Boolean;
function '<=' specializes NumericalFunctions::'<=' (x: Integer, y: Integer): Boolean;
function '>=' specializes NumericalFunctions::'>=' (x: Integer, y: Integer): Boolean;
function Max specializes NumericalFunctions::Max (x: Integer, y: Integer): Integer;
function Min specializes NumericalFunctions::Min (x: Integer, y: Integer): Integer;
function '==' specializes BaseFunctions::'==' (x: Integer, y: Integer): Boolean;
function '!=' specializes BaseFunctions::'!=' (x: Integer, y: Integer): Boolean;
function '..' specializes ScalarFunctions::'..' (lower: Integer, upper: Integer): Integer[0..*];
function ToString specializes BaseFunctions::ToString (x: Integer): String;
function ToNatural(x: Integer): Natural;
function ToInteger(x: String): Integer;
function ToRational(x: Integer): Rational;
function ToReal(x: Integer): Real;
function sum specializes ScalarFunctions::sum (collection: Integer[0..*]): Integer;
function product specializes ScalarFunctions::product (collection: Integer[0..*]): Integer;
}
99. SSTKernel
Unlimited Natural Functions
16 October 202099
package UnlimitedNaturalFunctions {
import ScalarValues::*;
function '<'specializes NumericalFunctions::'<'(x: UnlimitedNatural, y: UnlimitedNatural): Boolean;
function '>' specializes NumericalFunctions::'>'(x: UnlimitedNatural, y: UnlimitedNatural): Boolean;
function '<=' specializes NumericalFunctions::'<='(x: UnlimitedNatural, y: UnlimitedNatural):
Boolean;
function '>=' specializes NumericalFunctions::'>='(x: UnlimitedNatural, y: UnlimitedNatural):
Boolean;
function Max specializes NumericalFunctions::Min(x: UnlimitedNatural, y: UnlimitedNatural):
UnlimitedNatural;
function Min specializes NumericalFunctions::Max(x: UnlimitedNatural, y: UnlimitedNatural):
UnlimitedNatural;
function '=' specializes BaseFunctions::'=='(x: UnlimitedNatural, y: UnlimitedNatural): Boolean;
function '!=' specializes BaseFunctions::'!='(x: UnlimitedNatural, y: UnlimitedNatural): Boolean;
function ToString specializes BaseFunctions::ToString(x: UnlimitedNatural): String;
function ToNatural(x: UnlimitedNatural): Natural;
function ToUnlimitedNatural(x: String): UnlimitedNatural;
}
100. SSTKernel
Natural Functions
16 October 2020100
package NaturalFunctions {
import ScalarValues::*;
function '+' specializes IntegerFunctions::'+' (x: Natural, y: Natural[0..1]): Natural;
function '*' specializes IntegerFunctions::'*' (x: Natural, y: Natural): Natural;
function '/' specializes IntegerFunctions::'/' (x: Natural, y: Natural): Natural;
function '%' specializes IntegerFunctions::'%' (x: Natural, y: Natural): Natural;
function '<' specializes IntegerFunctions::'<', UnlimitedNaturalFunctions::'<'
(x: Natural, y: Natural): Boolean;
function '>' specializes IntegerFunctions::'>', UnlimitedNaturalFunctions::'>'
(x: Natural, y: Natural): Boolean;
function '<=' specializes IntegerFunctions::'<=', UnlimitedNaturalFunctions::'<='
(x: Natural, y: Natural): Boolean;
function '>=' specializes IntegerFunctions::'>=', UnlimitedNaturalFunctions::'>='
(x: Natural, y: Natural): Boolean;
function Max specializes IntegerFunctions::Max, UnlimitedNaturalFunctions::Max
(x: Natural, y: Natural): Natural;
function '==' specializes IntegerFunctions::'==', UnlimitedNaturalFunctions::'='
(x: UnlimitedNatural, y: UnlimitedNatural): Boolean;
function '/=' specializes IntegerFunctions::'!=', UnlimitedNaturalFunctions::'!='
(x: UnlimitedNatural, y: UnlimitedNatural): Boolean;
function ToString specializes IntegerFunctions::ToString,UnlimitedNaturalFunctions::ToString
(x: Natural): String;
function ToNatural(x: String): Natural;
}
101. SSTKernel
Rational Functions
16 October 2020101
package RationalFunctions {
import ScalarValues::*;
function Rat(numer: Integer, denum: Integer): Rational;
function Numer(rat: Rational): Integer;
function Denom(rat: Rational): Integer;
function Abs specializes NumericalFunctions::Abs (x: Rational): Rational;
function '+' specializes NumericalFunctions::'+' (x: Rational, y: Rational[0..1]): Rational;
function '-' specializes NumericalFunctions::'-' (x: Rational, y: Rational[0..1]): Rational;
function '*' specializes NumericalFunctions::'*' (x: Rational, y: Rational): Rational;
function '/' specializes NumericalFunctions::'/' (x: Rational, y: Rational): Rational;
function '**' specializes NumericalFunctions::'**' (x: Rational, y: Rational): Rational;
function '<' specializes NumericalFunctions::'<' (x: Rational, y: Rational): Boolean;
function '>' specializes NumericalFunctions::'>' (x: Rational, y: Rational): Boolean;
function '<=' specializes NumericalFunctions::'<=' (x: Rational, y: Rational): Boolean;
function '>=' specializes NumericalFunctions::'>=' (x: Rational, y: Rational): Boolean;
function Max specializes NumericalFunctions::Max (x: Rational, y: Rational): Rational;
function Min specializes NumericalFunctions::Min (x: Rational, y: Rational): Rational;
function '==' specializes BaseFunctions::'==' (x: Rational, y: Rational): Boolean;
function '!=' specializes BaseFunctions::'!=' (x: Rational, y: Rational): Boolean;
function GCD(x: Rational, y: Rational): Integer;
function Floor(x: Rational): Integer;
function Round(x: Rational): Integer;
function ToString specializes BaseFunctions::ToString (x: Rational): String;
function ToInteger(x: Rational): Integer;
function ToRational(x: String): Rational;
function ToReal(x: Rational): Real;
function ToComplex(x: Rational): Complex;
function sum specializes ScalarFunctions::sum(collection: Rational[0..*]): Rational;
function product specializes ScalarFunctions::product(collection: Rational[0..*]): Rational;
}
102. SSTKernel
Real Functions
16 October 2020102
package RealFunctions {
import ScalarValues::*;
function Abs specializes NumericalFunctions::Abs (x: Real): Real;
function '+' specializes NumericalFunctions::'+' (x: Real, y: Real[0..1]): Real;
function '-' specializes NumericalFunctions::'-' (x: Real, y: Real[0..1]): Real;
function '*' specializes NumericalFunctions::'*' (x: Real, y: Real): Real;
function '/' specializes NumericalFunctions::'/' (x: Real, y: Real): Real;
function '**' specializes NumericalFunctions::'**' (x: Real, y: Real): Real;
function '<' specializes NumericalFunctions::'<' (x: Real, y: Real): Boolean;
function '>' specializes NumericalFunctions::'>' (x: Real, y: Real): Boolean;
function '<=' specializes NumericalFunctions::'<=' (x: Real, y: Real): Boolean;
function '>=' specializes NumericalFunctions::'>=' (x: Real, y: Real): Boolean;
function Max specializes NumericalFunctions::Max (x: Real, y: Real): Real;
function Min specializes NumericalFunctions::Min (x: Real, y: Real): Real;
function '==' specializes BaseFunctions::'==' (x: Real, y: Real): Boolean;
function '!=' specializes BaseFunctions::'!=' (x: Real, y: Real): Boolean;
function Sqrt(x: Real): Real;
function Floor(x: Real): Integer;
function Round(x: Real): Integer;
function ToString specializes BaseFunctions::ToString (x: Real): String;
function ToInteger(x: Real): Integer;
function ToRational(x: Real): Rational;
function ToReal(x: String): Real;
function ToComplex(x: Real): Complex;
function sum specializes ScalarFunctions::sum (collection: Real[0..*]): Real;
function product specializes ScalarFunctions::product (collection: Real[0..*]): Real;
}
103. SSTQuantities and Units
Quantities
16 October 2020
package Quantities {
abstract attribute def QuantityValue :> ScalarValues::NumericalValue {
attribute num : ScalarValues::Number;
attribute mRef : UnitsAndScales::MeasurementReference;
}
attribute quantity : QuantityValue;
}
A quantity value is a numerical
value that represents the
value of a quantity.
The num is the mathematical
number value of the quantity.
The value of a quantity is
relative to a measurement
reference, which may be a
measurement unit if the
scale is a ratio scale.A quantity is a usage of a
quantity value to represent
a feature of something.
103
104. SSTQuantities and Units
Units
16 October 2020
package UnitsAndScales {
attribute def MeasurementReference {
attribute name : ScalarValues::String;
attribute scaleValueDefinition : ScaleValueDefinition[0..*];
}
abstract attribute def MeasurementUnit :> MeasurementReference {
attribute unitPowerFactor : UnitPowerFactor[1..*] ordered;
attribute unitConversion : UnitConversion[0..1];
}
abstract value type SimpleUnit :> MeasurementUnit {
attribute redefines unitPowerFactor[1] {
attribute redefines unit = SimpleUnit::self;
attribute redefines exponent = 1;
}
}
abstract attribute def DerivedUnit :> MeasurementUnit;
attribute def UnitPowerFactor {
attribute unit : MeasurementUnit;
attribute exponent : ScalarValues::Number;
}
…
}
A measurement unit is a
measurement scale defined as a
sequence of unit power factors.
A simple unit is a measurement
unit with no power factor
dependencies on other units.
A derived unit is any unit that is
not simple.
A unit power factor is a
representation of a unit
raised to an exponent.
104
105. SSTQuantities and Units
International System of Quantities (ISQ)
16 October 2020
package ISQSpaceTime {
attribute def LengthUnit :> SimpleUnit;
attribute def LengthValue :> QuantityValue {
attribute redefines num : ScalarValues::Real;
attribute redefines mRef : LengthUnit;
}
attribute length: LengthValue :> quantity;
…
}
A length unit is a simple unit.
A length value is a quantity
value with a real magnitude
and a length-unit scale.
A length is a quantity with a
length value.
105
package ISQ {
import ISQSpaceTime::*;
…
}
The International System of Quantities
defines seven abstract units (length, mass,
time, electric current, temperature,
amount of substance, luminous intensity)
and many other units derived from those.
The ISQ standard (ISO 80000)
is divided into several parts. For
example, Part 3 defines units
related to space and time.
106. SST
Quantities and Units
International System of Units /
Système International (SI)
16 October 2020
package SI {
import ISQ::*;
import SIPrefixes::*;
attribute g : MassUnit { redefines name = "gram"; }
attribute m : LengthUnit { redefines name = "metre"; }
attribute kg : MassUnit {
attribute redefines name = "kilogram";
attribute redefines unitConversion : ConversionByPrefix {
attribute redefines prefix = kilo;
attribute redefines referenceUnit = g;
}
}
attribute s : TimeUnit { redefines name = "second"; }
…
attribute N: ForceUnit = kg * m / s ** 2
{ redefines name = "newton"; }
The International System of
Units defines base units for the
seven abstract ISQ unit types.
A unit can be defined using
prefix-based conversion
from a reference unit.
A derived unit can be
defined from an arithmetic
expression of other units.
106
107. SSTQuantities and Units
US Customary Units
16 October 2020
package USCustomaryUnits {
import ISQ::*;
attribute ft : LengthUnit {
attribute redefines name = "foot";
attribute redefines unitConversion : ConversionByConvention {
attribute redefines referenceUnit = m;
attribute redefines conversionFactor = 0.3048;
}
}
attribute mi : LengthUnit {
attribute redefines name = "mile",
attribute redefines unitConversion : ConversionByConvention {
attribute redefines referenceUnit = ft;
attribute conversionFactor = 5280.0;
}
}
attribute 'mi/hr' : SpeedUnit = mi / hr
{ redefines name = "mile per hour"; }
alias 'mi/hr’ as mph;
…
}
US customary units are defined
by conversion from SI units.
An alias for mile per hour.
107