Computer Assisted Engineering for Robotics and Autonomous Systems - - PowerPoint PPT Presentation

▶
computer assisted engineering for robotics and autonomous
SMART_READER_LITE
LIVE PREVIEW

Computer Assisted Engineering for Robotics and Autonomous Systems - - PowerPoint PPT Presentation

Jan 08, 2023 981 likes •1.43k views

Computer Assisted Engineering for Robotics and Autonomous Systems Development and Adoption of Model-Based Tools in Robotics Christian Schlegel Alex Lotz, Matthias Lutz, Dennis Stampfer Computer Science Department University of Applied Sciences

slide-1
SLIDE 1

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 1

Computer Assisted Engineering for Robotics and Autonomous Systems Development and Adoption of Model-Based Tools in Robotics

Christian Schlegel Alex Lotz, Matthias Lutz, Dennis Stampfer Computer Science Department University of Applied Sciences Ulm, Germany http://www.servicerobotik-ulm.de/ https://www.youtube.com/user/RoboticsAtHsUlm

slide-2
SLIDE 2

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 2 ECHORD++ MARS Experiment http://www.fendt.com/int/11649.asp iserveU Final Report iserveU hospital logistics Intralogistics OpenRobotino KMU Innovativ

slide-3
SLIDE 3

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 3

https://youtu.be/KH7FJnNO3z4

slide-4
SLIDE 4

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 4

Cooperative Robot Butler Scenario

slide-5
SLIDE 5

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 5

https://youtu.be/DjjNUPpj36E

slide-6
SLIDE 6

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 6

IEEE Spectrum, October 1995 Paper describes how Boeing built the 777 with thousands of workers, with many companies around the world, doing everything by software (from design over manufacturing to checking the software) Resulted in tremendous cut in costs and cut in time to manufacturing

Development and Adoption of Model-Based Tools in Robotics

slide-7
SLIDE 7

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 7

from DNA „programs“ to „devices“ / living organisms

  • from CAD schematics to chips
  • Boeing 777 (1986-1994) / Boeing 787 (2004-2009)
  • Cyber-Physical Systems (CPS) (2008…)
  • Social networks mushroomed over the Web
  • Economic networks mushroomed over the Web
  • Renewable energy, smart grids
  • …

(based on John S. Baras / 2003 White Symposium)

Existence Proof: How biology builds complex systems… The Beauty in Systems Engineering… Where we are…

  • rganism
  • rgan

system

  • rgan

tissue cell

Overall challenge: we need to provide technical solutions that

  • provide great performance
  • are safe, secure, robust, resilient, predictable, conformant to legal and ethical norms, etc.
  • are affordable, economically justifiable, manageable etc.

information + software + physical components + humans

Development and Adoption of Model-Based Tools in Robotics

slide-8
SLIDE 8

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 8

Computer Assisted Engineering for Robotics and Autonomous Systems Development and Adoption of Model-Based Tools in Robotics

  • computer aided engineering
  • computer assisted engineering
  • computer assisted software engineering
slide-9
SLIDE 9

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 9

Topic Group Software Engineering, System Integration, System Engineering

Development and Adoption of Model-Based Tools in Robotics

slide-10
SLIDE 10

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 10

Modeling languages that are not executable, or where the execution semantics is vague or undefined are not much better than TUML:

  • interested in executable models only

(not in descriptive models, declarative models fine as long as they come with solvers)

  • focus on concurrent components that communicate via ports

(as one might describe in SysML, AADL, etc., though I will be more specific than these) We can do better! We need do better!

(based on Edward Lee,Berkeley, http://models2010.ifi.uio.no/material/Heterogeneous_Models.pdf)

The Truly Unified Modeling Language TUML

  • notice how nicely formal the language is!
  • tools already exist
  • with the mere addition of a TUML profile,

every existing UML notation is a special case!

Examples of TUML languages:

Development and Adoption of Model-Based Tools in Robotics

slide-11
SLIDE 11

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 11

http://design.ros2.org/articles/why_ros2.html

Development and Adoption of Model-Based Tools in Robotics

Example ROS: Purely source code-driven, implementation-driven ecosystem

slide-12
SLIDE 12

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 12 source: Marco di Natale

Fine-grained functional graphs mapped onto complex distributed architecture

  • AUTOSAR:

timing constraints meant to describe timing chains for the main purpose

  • f worst-case timing analysis:
  • not for specifying timings
  • not related to QoS (no link to implications of

modified cycle times etc.)

  • not to support deployment
  • …
  • MARTE profile

(OMG standard for real-time and embedded systems):

  • too large
  • difficult to use
  • union of needs/requirements from too many

sources

  • OMG MDA (model-driven architecture):
  • too linear workflow PIM –> PSM –> PSI
  • Implementations abstract away relevant

properties like QoS, resource awareness, etc.

  • …

Development and Adoption of Model-Based Tools in Robotics

slide-13
SLIDE 13

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 13

  • scientific modeling
  • models in engineering
  • building a model requires abstraction
  • assumptions are used in modeling in order to specify the domain
  • a system is a set of interacting or independent entities, real or abstract, forming an integrated whole
  • composability is the ability to combine and recombine as-is building blocks into different systems for

different purposes. It requires that properties of sub-systems are invariant („remain satisfied“) under composition.

  • splittability is the „inverse“ relationship of composability.
  • compositionality requires that the behavior of a system is predictable from its sub-systems and that of the

composition „glue“.

  • system composition (activity): the activity of putting together a set of existing building blocks to match

system needs with a focus on flexible (re-)combination.

  • system integration (activity): the activity that requires effort to combine components, requiring

modifications or additional actions to make them work with others.

  • structural model of the system: what the system consists of?

=> robot base, manipulator, laser ranger, SLAM, object recognition, HRI, …

  • behavioral model of the system: what the system does?

=> deliver coffee, grasp cup, operate coffee machine, … All can be block diagrams with hierarchy. The difficult part is the mapping between behavior and structure.

Development and Adoption of Model-Based Tools in Robotics

slide-14
SLIDE 14

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 14

Can we think of complex robotic systems before we start constructing them?

  • there will be no single architecture („the“ reference architecture) as „architecture“ is for something
  • architectures are linked to properties like resilience, robustness, …
  • do not abstract away relevant aspects
  • resources
  • extra-functional properties (how to execute a functionality)
  • do not ignore relevant means to deal with complexity
  • separation of concerns
  • composability

How to build models from all the heterogeneous sciences for different parts and aspects of a robotic system?

  • be able to put together the models / link the models quickly and correctly
  • be at least as detailed as needed for a certain level of confidence into the properties of the outcome

(by simulation, by testing, by reasoning, …)

Development and Adoption of Model-Based Tools in Robotics

You cannot go through all combinations of all parameters in order to know about the properties of your

  • system. Your need to be able to answer „what if“ questions with design exploration tools which give the

answers quickly and are user-friendly (trade-off analysis, multi-criteria-optimization, constraint-based reasoning all composed)

slide-15
SLIDE 15

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 15

  • hook heterogeneous models
  • cannot be done easily as long as you do not adopt to a notion of Meta-Models
  • Meta-models allow to transform in a consistent way between models including constraints,

tolerances etc.

(John S. Baras / 2016 ETFA / https://youtu.be/oXAZEIZc5Zs?t=1354 )

Development and Adoption of Model-Based Tools in Robotics

slide-16
SLIDE 16

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 16

vertical / composable horizontal / composable

Development and Adoption of Model-Based Tools in Robotics

slide-17
SLIDE 17

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 17

Development and Adoption of Model-Based Tools in Robotics

slide-18
SLIDE 18

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 18

computation communication coordination configuration

achieve separation of roles support composition

Development and Adoption of Model-Based Tools in Robotics

User

Which patterns and structures form the Sweet Spot between Freedom of Choice and Freedom from Choice? Guidance for separation of concerns by superordinate

  • bjectives like the need for separation of roles and the

need for composition Support as much freedom as possible while still ensuring composability despite separation of roles

slide-19
SLIDE 19

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 19

Business Ecosystem

A business ecosystem describes the structure and behaviour of a network of high-tech organisations that share a key technological platform and the ways individual firms can flourish in such an environment.

[Moore, James F., 1993]

A business ecosystem is “a dynamic structure which consists

  • f an interconnected population of organisations. A business

ecosystem develops through self-organisation, emergence and co-evolution, which help it to acquire adaptability. In a business ecosystem there is both competition and cooperation present simultaneously”

[Peltoniemi & Vuori2005]

Structures:

  • Separation of Roles
  • Separation of Concerns
  • Composability and Composition of building blocks
  • Freedom of Choice versus Freedom from Choice

(Standards) Benefits:

  • share and lower risks, efforts & costs
  • improve robustness, quality, time-to-market, cost-efficiency
  • agile and effective collaboration to support commercialization
  • easy entry for niche players to effectively fill gaps and to evolve
  • delay design decisions to the latest point that is economically

feasible

slide-20
SLIDE 20

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 20

Business Ecosystem

A business ecosystem describes the structure and behaviour of a network of high-tech organisations that share a key technological platform and the ways individual firms can flourish in such an environment.

[Moore, James F., 1993]

A business ecosystem is “a dynamic structure which consists

  • f an interconnected population of organisations. A business

ecosystem develops through self-organisation, emergence and co-evolution, which help it to acquire adaptability. In a business ecosystem there is both competition and cooperation present simultaneously”

[Peltoniemi & Vuori2005]

Structures:

  • Separation of Roles
  • Separation of Concerns
  • Composability and Composition of building blocks
  • Freedom of Choice versus Freedom from Choice

(Standards) Benefits:

  • share and lower risks, efforts & costs
  • improve robustness, quality, time-to-market, cost-efficiency
  • agile and effective collaboration to support commercialization
  • easy entry for niche players to effectively fill gaps and to evolve
  • delay design decisions to the latest point that is economically

feasible

Expert Domain 1 „Cleaning“ <Role B> Expert Domain 2 „Logistics“ <Role B> <Role B> <Role B>

Application Domain step change Freedom of choice (e.g. ROS, etc.) Freedom from choice (SmartSoft, AUTOSAR, Standardization, etc.)

  • not a universal positive
  • does not want to enforce any

architectural design decisions for developers

  • high price to pay since there is

no guidance with respect to ensuring composability and system level conformance

  • not a universal negative
  • Architectural patterns should impose structures only

as far as these cannot be achieved at a more local level (subsidiarity principle)

  • Structures that ensure composability restrict

freedom of choice to achieve system level conformance

slide-21
SLIDE 21

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 21

Business Ecosystem

A business ecosystem describes the structure and behaviour of a network of high-tech organisations that share a key technological platform and the ways individual firms can flourish in such an environment.

[Moore, James F., 1993]

A business ecosystem is “a dynamic structure which consists

  • f an interconnected population of organisations. A business

ecosystem develops through self-organisation, emergence and co-evolution, which help it to acquire adaptability. In a business ecosystem there is both competition and cooperation present simultaneously”

[Peltoniemi & Vuori2005]

Structures:

  • Separation of Roles
  • Separation of Concerns
  • Composability and Composition of building blocks
  • Freedom of Choice versus Freedom from Choice

(Standards) Benefits:

  • share and lower risks, efforts & costs
  • improve robustness, quality, time-to-market, cost-efficiency
  • agile and effective collaboration to support commercialization
  • easy entry for niche players to effectively fill gaps and to evolve
  • delay design decisions to the latest point that is economically

feasible Communication Objects Services Components Systems Middleware H/W

  • from services to components:

provide functionality by grouping services to components

  • components as grey boxes:

express how parameter settings (modes) influence each other in terms of resulting quality of service Architecture

10ms

  • requirements in terms of QoS, timings etc.:

application drives requirements

  • ffered

required configure to match requirements

  • select / compose / configure according to

architecture: inject timing into execution container and communication patterns and select appropriate settings out of offered ones in order to match architectural requirements

slide-22
SLIDE 22

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 22

http://youtu.be/DjjNUPpj36E

same services but assigned differently to components newly added component replaced component

Development and Adoption of Model-Based Tools in Robotics

slide-23
SLIDE 23

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 23

Development and Adoption of Model-Based Tools in Robotics

slide-24
SLIDE 24

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 24

Development and Adoption of Model-Based Tools in Robotics

slide-25
SLIDE 25

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 25

slide-26
SLIDE 26

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 26

slide-27
SLIDE 27

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 27

slide-28
SLIDE 28

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 28

slide-29
SLIDE 29

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 29

slide-30
SLIDE 30

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 30

https://youtu.be/JIYPJXmop3U

slide-31
SLIDE 31

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 31

slide-32
SLIDE 32

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 32

  • Lotz, A., Hamann, A., Lange, R., Heinzemann, C., Staschulat, J., Kesel, V., Stampfer, D., Lutz, M., and Schlegel, C. Combining

Robotics Component-Based Model-Driven Development with a Model-Based Performance Analysis. In IEEE International Conference on Simulation, Modeling, and Programming for Autonomous Robots (SIMPAR), 2016, San Francisco, CA, USA.

  • Dennis Stampfer, Alex Lotz, Matthias Lutz and Christian Schlegel. "The SmartMDSD Toolchain: An Integrated MDSD

Workflow and Integrated Development Environment (IDE) for Robotics Software". Special Issue on Domain-Specific Languages and Models in Robotics, Journal of Software Engineering for Robotics (JOSER), 7(1), 3-19 ISSN: 2035-3928, July 2016.

  • Alex Lotz, Arne Hamann, Ingo Lütkebohle, Dennis Stampfer, Matthias Lutz, Christian Schlegel. Modeling Non-Functional

Application Domain Constraints for Component-Based Robotics Software Systems. In 6th International Workshop on Domain-Specific Languages and models for ROBotic systems (DSLRob-15), Hamburg, October, 2015.

  • Christian Schlegel, Alex Lotz, Matthias Lutz, Dennis Stampfer, Juan F. Inglés-Romero, and Cristina Vicente-Chicote. "Model-

driven software systems engineering in robotics: Covering the complete life-cycle of a robot", in Journal IT - Information Technology: Methods and Applications of Informatics and Information Technology, Volume 57, Issue 2, Pages 85–98, ISSN (Online) 2196-7032, ISSN (Print) 1611-2776, DOI: 10.1515/itit-2014-1069, DE GRUYTER, March 2015.

  • Alex Lotz, Juan F. Ingles-Romero, Dennis Stampfer, Matthias Lutz, Cristina Vicente-Chicote and Christian Schlegel. "Towards

a Stepwise Variability Management Process for Complex Systems – A Robotics Perspective", in International Journal of Information System Modeling and Design (IJISMD 2014), DOI: 10.4018/ijismd.2014070103, 5(3):55-74, 2014.

References

slide-33
SLIDE 33

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 33

Addendum

slide-34
SLIDE 34

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 34

Variability Management in the Lifecycle

slide-35
SLIDE 35

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 35

Meta-Model Real robot in real world Eclipse-Toolchain

  • component

developer

  • software

component

  • execution

container

SmartMDSD (service oriented component model)

  • Meta-Model
  • Toolchain

SmartSoft (implementation)

  • CORBA / SmartSoft
  • ACE / SmartSoft
  • Linux, Windows, etc.

SmartTCL (Task Coordination Language) VML (Variability Modeling Language)

Eclipse-Toolchain

  • system integrator
  • deployment

Variability Management in the Lifecycle

Domain Specific Languages

slide-36
SLIDE 36

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 36

Software Variability and Runtime Reconfiguration

Software Variability: Variability in Operation: Variability in Quality: Technology Driven Application Driven Environment Driven How to do it?

  • pure task achievement
  • robot functionality

What is a good way to do it?

  • do it efficiently
  • which possibilities are

better than others in terms

  • f non-functional properties

contexts, rules, properties, variation points task sequencing, composable subtasks Design Time Run-Time deliver product with explicated variation points. Exploit and bind left open variation points. Components Services System of Components DSL DSL Meta Model Objective: Maintain a high success rate in task fulfillment => sequencing actions Objective: Improve overall execution quality => optimizing non-functional properties Objective: Composability

slide-37
SLIDE 37

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 37

Software Variability and Runtime Reconfiguration

Software Variability: Variability in Operation: Variability in Quality: Technology Driven Application Driven Environment Driven How to do it?

  • pure task achievement
  • robot functionality

What is a good way to do it?

  • do it efficiently
  • which possibilities are

better than others in terms

  • f non-functional properties

contexts, rules, properties, variation points task sequencing, composable subtasks Design Time Run-Time deliver product with explicated variation points. Exploit and bind left open variation points. Components Services System of Components DSL DSL Meta Model

slide-38
SLIDE 38

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 38

Software Variability and Runtime Reconfiguration

Software Variability: Variability in Operation: Variability in Quality: Technology Driven Application Driven Environment Driven How to do it?

  • pure task achievement
  • robot functionality

What is a good way to do it?

  • do it efficiently
  • which possibilities are

better than others in terms

  • f non-functional properties

contexts, rules, properties, variation points task sequencing, composable subtasks Design Time Run-Time deliver product with explicated variation points. Exploit and bind left open variation points. Components Services System of Components DSL DSL Meta Model

Services as basic architectural entities:

  • guarantee that supplied components can be integrated into concrete applications
  • keep the architecture and implementation containers flexible
  • allow to identify white spots as early as possible (required services that no-one provides or

provided services that no-one requires). Component Level:

  • aggregates services to components or groups of components
  • might contain competing alternative components providing the same services from different

suppliers with different characteristics

  • both open source and closed source implementations can be used since one can rely on service

descriptions

  • even though components implement functionalities, the granularity of components is arbitrary and

not decisive for the architecture. Component granularity might differ from application to application, whereas the granularity of services can remain the same. Concrete Applications:

  • are composed from building blocks
slide-39
SLIDE 39

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 39

Software Variability and Runtime Reconfiguration

Software Variability: Variability in Operation: Variability in Quality: Technology Driven Application Driven Environment Driven How to do it?

  • pure task achievement
  • robot functionality

What is a good way to do it?

  • do it efficiently
  • which possibilities are

better than others in terms

  • f non-functional properties

contexts, rules, properties, variation points task sequencing, composable subtasks Design Time Run-Time deliver product with explicated variation points. Exploit and bind left open variation points. Components Services System of Components DSL DSL Meta Model Service-oriented Component Model and MDSD-workflow Eclipse based SmartMDSD Toolchain Black-Box View

slide-40
SLIDE 40

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 40

Software Variability and Runtime Reconfiguration

Software Variability: Variability in Operation: Variability in Quality: Technology Driven Application Driven Environment Driven How to do it?

  • pure task achievement
  • robot functionality

What is a good way to do it?

  • do it efficiently
  • which possibilities are

better than others in terms

  • f non-functional properties

contexts, rules, properties, variation points task sequencing, composable subtasks Design Time Run-Time deliver product with explicated variation points. Exploit and bind left open variation points. Components Services System of Components DSL DSL Meta Model SmartTCL: Task Coordination Language

slide-41
SLIDE 41

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 41

Software Variability and Runtime Reconfiguration

Software Variability: Variability in Operation: Variability in Quality: Technology Driven Application Driven Environment Driven How to do it?

  • pure task achievement
  • robot functionality

What is a good way to do it?

  • do it efficiently
  • which possibilities are

better than others in terms

  • f non-functional properties

contexts, rules, properties, variation points task sequencing, composable subtasks Design Time Run-Time deliver product with explicated variation points. Exploit and bind left open variation points. Components Services System of Components DSL DSL Meta Model VML: Variability Modeling Language

slide-42
SLIDE 42

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 42

Software Variability and Runtime Reconfiguration

Software Variability: Variability in Operation: Variability in Quality: Technology Driven Application Driven Environment Driven How to do it?

  • pure task achievement
  • robot functionality

What is a good way to do it?

  • do it efficiently
  • which possibilities are

better than others in terms

  • f non-functional properties

contexts, rules, properties, variation points task sequencing, composable subtasks Design Time Run-Time deliver product with explicated variation points. Exploit and bind left open variation points. Components Services System of Components DSL DSL Meta Model VML: Variability Modeling Language

slide-43
SLIDE 43

Christian Schlegel, Schloss Dagstuhl, 13.02.2017 43

System Architecture: Execution Variants at Run-Time