Model Based System Engineering – Concept
Systems engineering is an interdisciplinary approach which enables development of system in a systematic manner. It focuses on every aspect of system lifecycle, right from defining customer needs, documenting requirements, design synthesis, validation, manufacturing, till system disposal. Systems today involve more electronics driven by more software and comparatively less hardware
and have become complex as there is an increased demand for intelligence and automation aiming to achieve user comfort and connectivity with internal and external world. All this has led to a considerable increase in number of the system requirements, system specific use cases and scenarios, interfaces and interactions leading to additional effort in overall engineering which demands for strong systems engineering processes supported by right set of tools. OEMs today are exploring Model based system engineering as a solution to challenges addressed by traditional system engineering methods.
Model Based Systems Engineering (MBSE) represents the methodology to perform & support system engineering activities such as system requirements, design, analysis, verification and validation. Systems Modeling Language (SysML) and MBSE can address today’s challenges of managing complex systems, maintaining and mapping of system and software architecture and changing requirements impacting the behavior.
Figure 1: Model Based System Engineering using SysML Modelling
Traditional system engineering methods are document based and leads to issues like difficult in understanding purely textual requirements and subject to individual interpretation, lack of consistency across engineering artefacts, incomplete traceability between upstream and downstream artefacts, lack of systematic information flow from one stage of system development to other. A system model created with capability to simulate the system behavior can help in enhancing the understanding of the system functional behavior, reduction in development time by detection of anomalies in requirements in early stages of the development life cycle. It also helps in defining appropriate interfaces, functional boundaries as inputs for implementation thereby enabling us to define complete system architecture for system under consideration.
Validation of system requirements before the implementation stage, ensures good quality specification being delivered for development. Increase in re usability right from requirements level helps in variant management and commonality Thus, MBSE discipline certainly contributes in creating a platform for impact assessment, bi-directional traceability at an earlier phase of the development life cycle.
The process of model based system engineering starts with analysis of high level requirements which are further detailed or enhanced through SysML modelling activity where in below snapshot explains how there is a transition from requirements to structure, behaviour and finally the system architecture. There is also a possibility of performing early behavioural simulation to validate the input requirements as well as feature/system which is envisioned.
Figure 2: Model Based System Engineering for Vehicle Feature/System/Function
Model based system engineering spans across complete application lifecycle management and product lifecycle management with SysML model acting as a central entity enabling connectivity between both the lifecycles.
As observed in the technical approach for model based system engineering, one of the key outputs is system architecture enabling system representation from different perspectives. This also further gets detailed to enable identification of appropriate hardware and software components, interfaces and functions.
This architecture acts as an input for further engineering activities and is a foundation for good and efficient system development. Too much of dependencies between various subsystems, grouping of un related functions under one subsystem, too many redundancies, etc. can cause issues in terms of development and testing activities consuming more time and poor future maintainability. An architecture can be created in multiple ways. However, which one is the better than other depends on multiple factors like measures
of effectiveness, maintainability and management aspects, engineering aspects etc.
We explain one such method which helps in evaluating a SysML based architecture with an objective of achieving good maintainability. Approach involves identifying the overall objectives of creating the architecture and relevant criteria against which architecture needs to
be evaluated. For ease of maintenance as criteria, we consider different metrics like, modifiability, architecture size and reusability based on which architecture can be evaluated.
Each of these metrics depend on several parameters which along with supporting mathematical function can help us arrive at metric value. These values can be compared against predefined threshold values thereby enabling categorization of the metric in good, average
or bad range. Based on the range in which metric falls, appropriate improvements and recommendations can be suggested. Below snapshot explains summary of one such evaluation for one of the subsystems in overall architecture and how it helps us identify issues
and improvement opportunities in a sample SysML architecture.
tr,td{border: 1px solid #000!important;padding: 10px;}
Battery Pack Monitoring and Control Parameters | |
Number of inputs in this subsystem | 1 |
Number of outputs in this subsystem | 2 |
Number of object inputs in this subsystem | 0 |
Number of control inputs in this subsystem | 1 |
Number of object outputs in this subsystem | 1 |
Number of control outputs in this subsystem | 1 |
Number of blocks connected at inputs in this subsystem | 0 |
Number of blocks connected at output in this subsystem | 1 |
Number of variation points in this subsystem | 0 |
Number of actions in this subsystem | 3 |
Number of forks in this subsystem | 0 |
Number of actions in fork in this subsystem | 0 |
Number of decision node in this subsystem | 2 |
Number of control flows in fork in this subsystem | 7 |
Number of object flows in fork in this subsystem | 0 |
Sum of input-output dependency for this subsystem | 0 |
Sum of individual action dependency of this subsystem | 1 |
tr,td{border: 1px solid #fff;padding:10px;}
Metric Name | Metric Value | Interpretation |
Complexity | 4.33 | High |
Metric Name | Metric Value | Interpretation |
Overall Coupling | 0.18 | Low |
Metric Name | Metric Value | Interpretation |
Cohesion | 0.17 | Low |
Metric Name | Metric Value | Interpretation |
Traceability | Medium | Medium |
tr,td{border: 1px solid #fff;padding: 10px;}
Metrics | Expected Value | Evaluated Value | Recommendation |
Complexity | Low | High | Reduce number of parallel paths/conditional branching in behavioral design |
Cohesion | High | Low | Reduce unrelated functions and allocate relevant functions in the subsystem |
Coupling | Low | Low | Coupling value is low as desired so no specific recommendation |
Traceability | High | Medium | Untraced requirements need to be traced with individual elements or architecture needs to be updated to cover such requirements |
Figure 3: Parameters Based Architecture Metrics Evaluation and Improvements
Such methodology helps in generating an architecture health report specifying architecture issues and aspects like data inconsistency across different diagrams, traceability of requirements with architecture elements, complexity of design, ease of testing and maintaining overall architecture, reusability quotient of architecture and many more such architectural aspects.
As we understand from earlier sections, in view of today’s complex systems and strict business requirements for shorter time to market and optimal cost of development, the model based system engineering along with supporting tools is helping the OEMs and Tier1s to streamline their overall system engineering processes and address the challenges posed by traditional system engineering processes and methodologies. However, for implementing model based system engineering, right domain experience in terms of the system to be developed as well as experience with right set of tools is required which along with supporting best practices from INCOSE and ISO/IEC system engineering standards.
The approach for Model based system engineering enables us to validate that we are developing right system at different stages of system development.
Author
Tanmay Agrawal,
SysML Modelling and MBSE Expert,
KPIT Technologies
14 likes
mechatronics
Systems engineering
14 likes
Connect with us
KPIT Technologies is a global partner to the automotive and Mobility ecosystem for making software-defined vehicles a reality. It is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. With 13000+ automobelievers across the globe specializing in embedded software, AI, and digital solutions, KPIT accelerates its clients’ implementation of next-generation technologies for the future mobility roadmap. With engineering centers in Europe, the USA, Japan, China, Thailand, and India, KPIT works with leaders in automotive and Mobility and is present where the ecosystem is transforming.
Plot Number-17,
Rajiv Gandhi Infotech Park,
MIDC-SEZ, Phase-III,
Hinjawadi, Pune – 411057
Phone: +91 20 6770 6000
Frankfurter Ring 105b,80807
Munich, GERMANY
Phone: +49 89 3229 9660
Fax: +49 89 3229 9669 99
KPIT and KPIT logo are registered trademarks | © Copyright KPIT for 2018-2024
CIN: L74999PN2018PLC174192
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Leave a Reply