Some lessons drawn from Systems Engineering (SE)

Freddy Kamdem Simo (see also)

September 6, 2021

SWISSED21

2

ObjectiveShow that challenges encountered with SE can also be encountered with Model-based SE

• As MBSE is simply an approach to the implementation of SE, the fundamental goal/problem - to satisfice* user needs under a multi-objective (cost, time, resources, etc.) and multi-domain (science, engineering, society, art, etc.) context - of SE should not be forgotten

Review these challenges and adverse-side effects and correlate them with some SE challenges

Introduce MODEF – a computational approach to cope with modelling activities understood as a technical-programmatic (or product-and-project) system (TPS)

Overview of related works

• Show how it can contribute to some SE challenges

Question about the development of SE

* A term coined by Simon Herbert

3

Outline

Some Systems Engineering challenges

Modelling activity (overview and obstacles)

Some results and lessons drawn from the literature

MODEF – contribution to systems engineering life cycle state space exploration

Summary and perspectives and questioning

4

Modelling Activity (overview and obstacles)

MBSE and Model-driven

Brown 2011

• yes, can foster better communications, representation, understanding, knowledgereuse and preservation, analysis, verification, etc.

When and why do obstacles arise with modelling activity?• If operated by autonomous stakeholders, within parallel and distributed tasks

• If involving specific and various business domains, methods, tools, formalisms, etc.

• If having different evolutions and long lifecycles (from weeks to years)

• Are creative and iterative

• but, the same problems (i.e. operation, analysis, traceability, reuse, etc.) as with documents might be encountered, i.e. risk of model proliferation

IT infrastructure and tools try to mitigate these obstacles, but the fundamentalproblem remains

5

Some Systems Engineering Challenges (1)

Difficulty in engineering of systems, limits of classical sciences

(Systems) methodologies/field

Rousseau et al 2016• have no or weak theoretical foundations

• lack firm scientific integrity and systemic nature

• cannot assess its own completeness and articulate its potential future value in a principled way

Integration, validation, collaboration, communication and traceability

Organisation and skills of the (socio-technical) system that addresses the fundamental problem

(systematically following processes is not enough)

(when does one work or fail? Why, how far does one work?)

Leveraging Digital Engineering (IT)

• has impacts on SE ecosystem (people, data, operations, methods, tools etc.)

6

Some Systems Engineering Challenges (2)

INCOSE SE VISION 2025

Focus

7

Some results and lessons drawn from SE evolution Probability, queuing, game, information Theories

Cybernetics General Systems Theory Dynamical Systems Design theory

Operations Research

Many other applied or methodological works on systems engineering, complexity, systems theories, systemic, engineering design, etc.

Handbooks (INCOSE, NASA, SEBok, etc.) and standards (Mil-STD-499, etc.)

SE ROI, some findings*• ROI cost (% SE cost on Program cost)

• No SE (0%) => 7:1 • Median level (7.2%) => 3.5:1 • (20%) => -2.8:1

• Technical leadership/management is unique in providing optimun program success simultaneously in cost, schedule and stakeholder acceptance

• No correlation founded between SE and system technical quality

Honour PhD thesis

*8 SE Activities are considered (Mission definition, Requirement Engineering, System Architecting, System Integration, V&V, Technical Analysis,

Scope management, Technical Management) for particular kinds of programs

Systems thinking

8

Lessons drawn from product-and-project system (TPS) design

Few works formally address the coupling of both sides (programmatic and technical)

Almost all works assume a design methodology for the technical side

Few works explicitly deal with the state of artefacts (e.g., models/data) related to the System to be made

Few evidence of formal requirements involved in model analysisi.e. what is formally expected from the system models of technical-programmatic system (TPS)?

Sharon et al 2008, 2011Vareilles et al 2015Wynn and Clarkson 2017

Kamdem Simo2017 PhD thesis

Tooling is both limited and a challenge (new tools and languages)

9

MODEF – contribution to SE life cycle state space exploration (1)Kamdem Simo 2017 PhD thesis

• Q1 How to abstract it?

Foundational challenge: how to formally deal with the technical-programmatic system (TPS)?

• Q2 What are its possible models and for which goals?

• Q3 How to reason on these models to achieve the goals?

• Q4 How to take advantage in practice of the answers of Q1, Q2 and Q3?

Practical challenge

• Q5 How to better understand TPS and models/data of the system to be made it produces

• Q6 How to analyse and identify the impact of TPS’ changes?

• Q7 How to help (using Q5 and Q6) in mastering TPS’ evolution?

Challenges

10

MODEF – contribution to SE life cycle state space exploration (2)

Abstraction of TPS

Iteratively Modelling an architecture of TPS

Reasoning on this architecture to improve TPS operation

Implementation and beyond (open and modular enablers based on formal foundations)

• Understanding TPS as a system (and federation of systems) at the level of itsarchitecture

• Expressing the expectations (or desired requirements) from this understanding

• Representing state, process, and conceptual views related to TPS

• Projecting requirements on these views

• Integrating state-of-the-art search/OR and model analysis algorithms

Principles

Kamdem Simo 2017 PhD thesis

11

MODEF – contribution to SE life cycle state space exploration (3)TPS Sample and instantiation of principles (formalism)

HFSM

Non-determinstic FSA

Graph

TRIGGER : PHY x TRANS →2^EVT

Ramadge and Wonham 1987

From A/G contractsto Assume/Preference formalism

Benveniste et al 2012

12

MODEF – contribution to SE life cycle state space exploration (4)TPS Sample and instantiation of principles (reasoning and informing )

A point (circle here) is couple of active states and events

Information• OK everything is ok• KO something is not ok• “ok” is problem and objective dependent

13

Summary and perspectivesMBSE may give rise to the same problems as those encountered with non-MBSE approaches

MBSE does not alter the fundamental goal or problem addressed by SE

A computational approach can help navigating in the foreseeable states (or situations) of a technical-programmatic system for in fine supporting decision making, risk identification, audit, validation and even certification

The coupling of technical and programmatic aspects of SE is vital to achieve the fundamental goal of SE, but poses many problems

Systems methodologies lack firm (when, why and how far can one work?) foundations

Modelling or SE activities can become difficult to master

14

Questioning on the development of SE

In the problem(s) that systems engineering seeks to solve, what is, or is there, a more important or critical aspect?

• Entirety vs neatness

Can we experiment in SE, different from observational studies encountered in economics?• engineering projects are unique, (almost) non-reproducible• SE is still much driven (necessary for the art leg of SE) by best practices, experts ->

challenges of reusing (prescriptive) knowledge• Short term vs long term

What is the position of SE in relation to a science of artificial as presented by H A Simon ?

Are predictions useful, desirable and/or possible in SE?• Not necessarily in a physical sense where a predetermined harmony can be assumed

ReferencesBrown 2011. Model-based systems engineering: Revolution or evolution. Thought Leadership White Paper. IBM RationalRousseau et al 2016. The synergy between general systems theory and the general systems worldview." Systema: connecting matter, life, culture and technology 4.1 (2016): 61-75INCOSE SE VISION 2025. https://www.incose.org/products-and-publications/se-vision-2025Honour PhD thesis. https://www.hcode.com/seroi/documents/SE-ROI%20Thesis-distrib.pdfSharon et al 2008. A project-product lifecycle management approach for improved systems engineering practices. INCOSE International Symposium, 18. 200Sharon et al 2011. Project management vs. systems engineering management: A practitioners' view on integrating the project and product domains. Systems Engineering, 2011, vol. 14Vareilles et al 2015. System design and project planning: Model and rules to manage their interactions. Integrated Computer-Aided Engineering, 22(4)Wynn and Clarkson 2017. Process models in design and development. Research in Engineering Design, 2018, vol. 29Kamdem Simo 2017 PhD thesis. https://tel.archives-ouvertes.fr/tel-01948889/documentKamdem Simo et al 2021. Principles for coping with the modelling activity of engineered systems. Research in Engineering Design, 2021, vol. 32Ramadge and Wonham 1987. Supervisory Control of a Class of Discrete Event Processes. SIAM Journal on Control and Optimization 25(1):206-230Benveniste et al 2012. Contracts for System Design https://hal.inria.fr/hal-00757488/documentKasser 2010. Seven systems engineering myths and the corresponding realities. Proceedings of the Systems Engineering Test and Evaluation Conference, Adelaide, Australia, 2010Simon 1996. The sciences of the artificial. 3rd Edition

Contact and more on systems enginering

frks@protonmail.ch

timeinx.com a proposal for an operational global vision of systems engineering

linkedin.com/in/ydderfs