Theme 4: MBSE applied to computing platforms and energy management
Theme 4:
MBSE applied to computing platforms and energy management
This theme is especially concerned with energy efficient computing and includes the better management of large distributed networks of devices. UTSA has demonstrated considerable advances in this area, with recent research demonstrating considerable power savings for large cloud computing networks. The emphasis of this theme will be on the use of MBSE to describe, and hence design large networks that dynamically reconfigure. Environmental modelling will also be important in this theme.
Theme 4: workshop interpretations
Although originally focused on energy efficient computing, the theme was more broadly interpreted by both the EU and US workshops as covering the use of MBSE for energy efficiency.
This usefully brought in aspects of modelling associated with smart grid.
There were two workshops:
1. San Antonio, Tx, March 2016
2. Kongsberg, Norway, June 2016 (this was associated with the IEEE SoSE conference)
State of the Art Participant
Presentations
Click on image above to view pdf
Click on image above to view pdf
Click on image above to view pdf
Click on image above to view pdf
Click on image above to view pdf
Click on image above to view pdf
Formal Methods for a System of Systems Analysis Framework
Applied to Traffic Management
Prof C.E. Dickerson, Dr S. Ji and R. Roslan
16 June 2016
Standards (e.g.) DO-178C, FTA approaches focus on definition and structuring of faults.
Behaviour modelling can support the discovery of faults
Motivation
MBSE with SysML supports behaviour modelling; SysML is graphical but not formal
IEEE SoSE 2014: Ingram, Andrews, Payne and Plat
DO-178C: Software Considerations in Airborne Systems & Equipment Certification FTA: Fault Tree Analysis
MBSE: Model Based Systems Engineering SysML: Systems Modeling Language RMS: Ramp Meter System
RMS Fault
Traffic Light Faults
No light Light Stuck
on Green
Incorrect Rate
Calculation
Fails to adopt
Collaborative
Mode
Operational Faults
Light Stuck
on Red
Fails to exist
Collaborative
Mode 1 1 3
2 4 5
fUML philosophy: precision by attaching executable notation (Alf) to UML models where behaviours can be a step towards formalisation of graphical models
Klir general system methodology
Semantic transformation techniques
Dependency Structure Matrices (DSM)
Basis of Approach
Attach Mathematical Matrix Representations of Behaviour to SysML Graphical Models
fUML: Foundational Unified Modeling Language Alf: Action Language for fUML SysML: Systems Modeling Language
Organize the elaborated Use Case into an Activity Diagram to make a complete description of behaviour
The structure of flow and control of activities can now be represented by the adjacency matrix of the graphical model
Application to the Case Study: Behavior Modeling
Application to the Case Study: Matrix Representation
Potential fault: 5. The RMS calculates an incorrect rate for vehicles to be
admitted
A framework for associating precise semantics with SysML behavioural models • Model specifications are guided by semantic transformation
• Formal analysis is based on matrix representation
Sematic Transformation: Next Steps • Matrix representation of Class/Block Diagram, State Machines
• Transformation (functional allocation ) of Activities to Classes
• Which provides insight for component level faults identification
Conclusions and Future Work
Identification of gaps
• What are the main gaps in MBSE relevant to Theme 4? o Rationale for identifying the gap?
Topics: • Understanding how distribution affects QoS such as energy
• Distribution: choices – client host (single machine), client with centralised remote server, decentralised control architecture, cloud
• Computation with your MBSE model executables • Security, resource consumption, energy management, performance for analysis (tabulate
against distribution) • Can be used to identify gaps in MBSE (systematically exploring each cell of the table)
• Does MBSE make any of these easier to understand or introduce new challenges? • Bridge conceptual level models with detailed level simulations
• Bringing detailed energy management simulations into MBSE • Collaboration between engineering domains & interoperability between engineering tools
• E.g. mechanical/electrical/other engineering tools do not integrate with those used by systems engineers
• To use MBSE / SysML other engineers need to be systems engineers • Encipher-ment and interface for crypto analysis implementation; privacy
• IP protection • MBSE can offer more than it does offer, instead of identifying behaviour of system it can offer fault
identification indirectly • Different cultures/viewpoints for MBSE in US/EU/Asia (need adaptation to local culture)
Collated answers
• What advances in MBSE are required to address the gaps? Topics: 1. Ease understanding/comprehension/readability of models
1. Models can be difficult to understand / communicate (e.g. Alloy, (formal) semantics of SysML)
2. Need a balance between formality and comprehension of notations 3. Is a philosophy such as fUML sufficient (back to basics, more precise, executable aspects)?
2. Is MBSE as it is today suitable for SoS? Implication is increased complexity in computing
3. Adapt multiple viewpoints (enterprise, human, …)
1. Traceability from higher levels (government or legal) to more detailed levels of the system
4. Code generators for real implementations from models
5. Network technology may provide a way to fill the gap of systems goes to SoS goes to enterprise
6. What level of model detail is needed for different stages of the CPS lifecycle?
7. Formal methods are needed for enterprise architecture modelling and simulation 1. Driven by analysis needs
Outputs: Dream Projects Theme 4 EU workshop, 16th June, 2016 – Kongsberg, Norway
Chaired by: Zoe Andrews, Newcastle University
Collaboration opportunities ideas & votes
Participants post-it notes
Collaboration in regard of the enterprise culture / “DNA” / working practice differences –
Geographically distributed MBSE: How to do: - Sharing - Security - Handle: culture differences
& time differences
To have a medium for users and researchers & providers in exchanging experience & knowledge & room for improvement
“Understanding & supporting geographically disperse MBSE” – 5votes • Electrical vehicle +
smartgrid + network … IoT – 3votes
• Modelling + Simulation of manufacturing environmental focusing data management and IoT
Collaboration opportunity Model Interchange and Exchange Aim: Create a PLA/Meta model that could be used to better align … model Objectives • Review ... • PLA state of Art • Formal PLA Methods
US & EU Tool vendor Collaboration Project
“Tool interoperability/model exchange/interchange” – 8votes
Dream Projects
1) Transatlantic standardised guide for cross-cultural MBSE 2) US and EU collaboration on MBSE tool PLA Standard
Dream Project TransAtlantic standardised guide for cross
cultural MBSE Team members:
Aim, objectives &
application domain
of the project
• Unified standardised guide for MBSE
• Understand cultural differences and agree on commonalities
• Provide case studies in successful collaborations
(Desired) US
contribution • Share successful use cases from US (MBSE)
• Share failed case as well
(Desired) EU
contribution • Share –”- EU
Collaboration
instruments.
Enablers & barriers
to collaboration.
• People may not want to share failed cases (-)
• Motivation is too low (-)
• Workshops to enable collaboration (+)
• Share tools & data only accessible through
collaboration (+)
Why should the
US/EU fund this
project (as opposed
to an alternative
funder)?
• Enable EUs leadership
• Benefits to EU wide standardisation
Baseline state of
the art (key existing
technologies)
INCOSE handbook, MODAF, DODAF, TOGAF, OMG?
Related roadmap
elements
Developments in M&S (Gaps): 1; 3; 5; 6 Collaboration opportunities:
Dream Project US & EU Collaboration on MBSE Tool PLA
Standard
PLA = software Product Line Architecture Team members:
Aim, objectives &
application domain
of the project
Aim: To create a formal PLA meta-model that could be used for international or industry standard to improve
MBSE tools for M&S
Objectives:
1) Review OMG Progress & PLA state of the art
2) Identify case/test studies
3) Formalise PLA Meta-model
4) Develop models
(Desired) US
contribution • Maturity in M&S tool
• Software Product Line Engineering Knowledge
(Desired) EU
contribution • Speciality in formal models
• Software expertise in models//tools exchange and interoperability
• Expertise in embedded systems & MBSE
Collaboration
instruments.
Enablers & barriers
to collaboration.
• Funding
• Workshops for vendors, users, & researchers to discuss project
Barrier: competition among tool vendors
Why should the
US/EU fund this
project (as opposed
to an alternative
funder)?
In the past years the development of MBSE tools are driven by US initiative. Progress is limited while skills of
EU researchers could potentially close current gaps in MBSE tool development.
This project has promise of success at the relevant level with US collaboration, but still offers EU incentive,
competitive advantage even if the US does not engage.
Baseline state of
the art (key existing
technologies)
OMG standards, all of the tool vendors and what they have
Vendors: US – IBM; NOMAGIC; PTC
EU: Modelio, SCADE
Related roadmap
elements
Developments in M&S (Gaps): 1; 3; 4; 7 Collaboration opportunities:
Collaboration Opportunity Ideas
1. Cloud-based modelling of real-time data
2. Big-data analytics modelling via machine learning
3. A platform could be established, such as this workshop, to understand the differences and commons to advance in CPSs, its tools and applications for having a better / suitable approaches
4. In EU, most of the researches aim public / society impact of the results. Therefore, we can learn from you. Especially in clean energy and public transportation. Since in US, transportation is the largest pie in energy
5. Sustainable energy sources are mostly deployed in EU; however there are concerns about the cost that affect society. Therefore, we can focus on to best applications in EU / secure & reliable ones / and compare with US
6. Identify tangible use cases with crisply defined objectives and not getting too complex in scope
7. Waste heat as a supplemental resource / W-t-e; part of the concept of net-zero buildings
Dream Project Big-data analytics modelling via machine
learning Team members:
Aim, objectives &
application domain
of the project
Explore ways to reduce energy usage using big data analysis and visualisation
Green buildings application domain
(Desired) US
contribution US energy data
Introduce PI System (OSIsoft) to EU
(Desired) EU
contribution Expertise in conservation and green buildings
Collaboration
instruments.
Enablers & barriers
to collaboration.
Joint workshop(s) on PI System , … (co-located or distributed)
1. Tutorial on what PI System is, everyone uses same data set. Use different tools to analyse / visualise the
data
2. Characterise energy usage on their own campus.
Why should the
US/EU fund this
project (as opposed
to an alternative
funder)?
Baseline state of
the art (key existing
technologies)
PI System
Analysis tools (e.g. Matlab)
Visualisation tools
Related roadmap
elements
Developments in M&S: Collaboration opportunities:
Outputs: Test Cases Theme 4 EU workshop, 16th June, 2016 – Kongsberg, Norway
Chaired by: Luminita Ciocoiu, Loughborough University
1) Transatlantic standardised guide for cross-cultural MBSE • Toyota Powertrain Benchmark ( 3 votes for DP1 and 2 votes for
DP2) • Civil engineering and SMART cities (3 votes for DP1) • New proposed Test Cases:
o Test Case for Autonomous Driving Vehicles
2) US and EU collaboration on MBSE tool PLA Standard
• Lane-change Scenario (4 votes for DP2) • Michigan M-City (3 votes for DP2 and 1 vote for DP1)
Test Cases associated with Dream Projects
Test Cases associated with Dream Project 1
Solution Selection Overview,
Purpose and
Structure of the
potential test
case
www. es. ucr.edu/~jinx Verification challenges for tools on hybrid sys. Includes various-complexity models with representative reqts + example tool perf. results. Different driver behaviour patterns. Different tools performance./interoperability of tools. Compatibility of tools/design Protection of sensitive information.
Organization/in
dividual
holding the test
case
Open source, see above. J. Xiaoqing et al. “Powertrain control verification benchmark”, HSCC 2014.
Procurement
protocol HTTP:CPS-VO.ORG/model/12108
Other
comments More benchmarks at: http://CPS-VO.ORG/GROUP/ARCH/BENCHMARKS
Potential Test
Case TOYOTA Powertrain Benchmark
Team
members:
Solution Selection
Overview, Purpose
and Structure of the
potential test case
Munich city is providing data, but may not be at the right level of fidelity.
Logistics fleet data (e.g. DHL) already exists. E.g. sensors on vehicles and in cab to
optimise.
Fidelity standard need be agreed
Automotive industry has good simulation tools for isolated vehicles (windchill tool –
virtual wind tunnel)
Agree on what tool to use
Gaming industry – game engines
Link to Collaboration
Opportunities/Dream
Projects
One above
Address Dream Project 1
Domain As above Civil engineering
Competency level:
Basic (now); Moderate
(3-5years); Advanced
(7-10years)
Whole time through – depending on the level of maturity.
Organization/individu
al holding the test
case
AVL (Austrian); Governments; Contractor.
PTC ; Automotive industry; regulatory body (SAE)
German projects (Bernard to provide details)
Procurement
protocol
Other comments
Potential Test
Case Civil engineering & SMART cities
Team
members:
Solution Selection Overview, Purpose
and Structure of the
potential test case
• Sensors (on-vehicle; infrastructure)
• Regulations (traffic; norms)
• Design and validate
• Fidelity
Link to Collaboration
Opportunities/Dream
Projects
1, 2
Domain Automotive (autonomous driving)
Competency level:
Basic (now); Moderate
(3-5years); Advanced
(7-10years)
Moderate (3-5 years)
Organization/individu
al holding the test
case
• 1 US company (Google?; Tesla?)
• Standardisation body
• 1 EU company (Volvo?)
• Governmental agencies
Procurement
protocol
Other comments
Potential Test
Case
Test Case for Autonomous Driving
Vehicles
Team
members:
Test Cases associated with Dream Project 2
Solution Selection Overview,
Purpose and
Structure of the
potential test
case
• Multi-x (disciplines, views)
• Human-machine interaction
• Uncertainty
- “Autonomy” (Functional Safety)
- Emergent behaviour
(unplanned Interplay)
(stochasticity)
• Collaboration
- Human-in-the-loop
- ITS Hierarchy
- Component-based
Organization/in
dividual
holding the test
case
• OFFIS on human behaviour in the loop
• Chalmers and VCC on Lane-change control. (to be checked)
• KTH (to be checked)
• Regulatory bodies
• Model/simulation developers
Procurement
protocol
NA
Other
comments
NA
Please include the two bullets from the Michigan M-City Potential Test Case
Potential Test
Case Lane-change Scenario
(scenario – “behaviour complexity”)
Team
members:
• Regulation details • Models & simulation
developed for the scenario
Solution Selection Overview,
Purpose and
Structure of the
potential test
case
A “mode” city where scenarios for autonomous vehicles can be
tested. – is there a model of the city?
Data gathered from these test scenarios can be used to validate
simulation approaches. For example:
- Human behaviour data to improve human behaviour models
- Sensor data (uncertainty, noise)
- Vehicle dynamics models
Organization/in
dividual
holding the test
case
U Mich, Ford, Google, Apple, etc. (Apple is doubtful)
Many companies may have this type of data.
Also London autonomous vehicle testing program.
Procurement
protocol - Collaboration between industry, academia, (possible government)
to standardise a model and data set and hopefully access to all.
Input/ Output
specification - A set of scenarios / test cases
Other
comments - Standardised model and data/ test cases should be necessary
for regulators to validate safety.
- Models and data/test cases suitable for testing tools and
languages against PLA meta-models
Potential Test
Case Michigan M-City
Team
members:
Solution Selection Overview, Purpose
and Structure of the
potential test case
Traffic Management SoS behaviours and Failures
- Existing MBSE models suitable for formal testing
- Sensor data
- Traffic management models
- SoS control architecture & strategies
Link to Collaboration
Opportunities/Dream
Projects
US & EU Collaboration on MBSE tools PLA standards
Domain Transportation
Competency level:
Basic (now); Moderate
(3-5years); Advanced
(7-10years)
Moderate (outputs and publications from COMPASS)
Organization/individu
al holding the test
case
COMPASS Deliverables: D24.2, D33.3, D43.3
www.compass_rsearch.eu/deliverables.html
Procurement
protocol
N/A for COMPASS
Some MBSE tools should be provided by vendor partners
Other comments
Potential Test
Case TM SoS Case Study
Team
members: