Formal Requirements Engineering for Smart Industries Alexandre Le - - PowerPoint PPT Presentation

▶
formal requirements engineering for smart industries
SMART_READER_LITE
LIVE PREVIEW

Formal Requirements Engineering for Smart Industries Alexandre Le - - PowerPoint PPT Presentation

Apr 02, 2023 373 likes •651 views

Formal Requirements Engineering for Smart Industries Alexandre Le Borgne, Nicolas Belloir, Jean-Michel Bruel, Thuy Nguyen * funded by a NeoCampus/IRIT grant 1 Content I. Context II. Graphical language Definition III. Results IV.

slide-1
SLIDE 1

Formal Requirements Engineering for Smart Industries

Alexandre Le Borgne, Nicolas Belloir, Jean-Michel Bruel, Thuy Nguyen

1

* funded by a NeoCampus/IRIT grant

slide-2
SLIDE 2

Content

  • I. Context

II. Graphical language Definition III. Results IV. Conclusions and future works

2

slide-3
SLIDE 3

Context

  • Main Concerns
  • Socio-CPS
  • Numerous factors which may

influence the behaviour of the system

  • Power plant => 60-years life-cycle
  • Intermittent renewable power

production

  • Numerous and wide uncertainties
  • Completeness of requirements
  • Ensure stability of the French

power grid

  • Early optimization
  • FORM-L (FOrmal Requirement

Modeling Language)

3

slide-4
SLIDE 4

Limitations

4 Functional Requirements and Use Cases, http: //www.bredemeyer.com SysML requirement diagram http://formalmind.com KAOS requirements http://foswiki.cs.uu.nl/

slide-5
SLIDE 5

FORM-L

  • Define the envelope of the system
  • Avoid over constraining
  • The model must not describe a solution
  • Model the environment of the

system as assumptions.

  • Formal expression of requirements
  • Simulation
  • Complex language
  • Several ways for defining

requirements → r1 ⬄ r2

property Model REQ class Pump external Boolean cavitates; external Boolean inOperation; end Pump; external Pump {} pumps; requirement r1= forAll p in pumps during p.inOperation check no p.cavitate; requirement r2 {} = { forAll pump in pumps | during p.inOperation check no p.cavitates }; end REQ; Pumps must not cavitate as long as they are operating.

5

slide-6
SLIDE 6

Problem

  • No FORM-L editor
  • Difficult to write for untrained people
  • Need of a graphical language
  • Visualize FORM-L concepts
  • Understand FORM-L models

→ FORM-GL

6

slide-7
SLIDE 7

Content

I. Context

  • II. Graphical language Definition

III. Results IV. Conclusions and future works

7

slide-8
SLIDE 8

FORM-GL requirements

  • Must be easy to understand
  • Untrained people
  • Different background
  • Different native language
  • Must be adaptable to the experience of the user
  • Beginner view
  • Expert view
  • Must be a compact language
  • No UML-like diagrams
  • Difficult to understand for untrained people
  • Difficult to read when they get to big
  • Must be a block language
  • Stick blocks together to get a compact and

understandable model

  • User might be able to define their own diagram

A boilerplate conception approach

8

slide-9
SLIDE 9

and c3

  • r

d4 ((a1+a2+a3)*a4) ≤ fnct(b1, b2+b3) and c3

  • r

d4 ≤ fnct(b1, b2+b3)

* +

a1 ((((a1+a2+a3)*a4) ≤ fnct(b1, b2+b3)) or c3) and d4 a2 a3 a4

slide-10
SLIDE 10

FORM-GL

Assembling blocks together Different representation levels

10

slide-11
SLIDE 11

Tools

EMF Xtext Sirius

  • Reference Eclipse tool for

designing metamodels

  • DSLs
  • Eclipse based tool
  • Create grammars
  • Eclipse based editor

implementing the grammar

  • Generates EMF meta-

model of the grammar

  • Eclipse based tool
  • Created and maintained

by Obeo

  • Creation of graphical

modeling tools based on EMF metamodels

  • Xtext integration extension

11

slide-12
SLIDE 12

Content

I. Context II. Graphical language Definition

  • III. Results

IV. Conclusions and future works

12

slide-13
SLIDE 13

13

slide-14
SLIDE 14

Results

  • FORM-L Grammar
  • Derive meta-model from the grammar
  • 195 meta-classes
  • FORM-L Editor
  • Syntax coloration
  • Syntax verification

14

slide-15
SLIDE 15

Results

  • FORM-GL Editor
  • Navigation within diagrams
  • Generation of FORM-L from a graphical model
  • And vice-versa
  • Integration of an Xtext

embedded editor into the graphical editor

  • Directly change the Xtext

expression of a FORM-L element from the graphical editor

15

slide-16
SLIDE 16

Results

  • Issues
  • Define and anchor text fields into a node

➢ Floating nodes that contain the text

➢ But not satisfying regarding the way we want to develop FORM-GL

  • Define topological constraints

➢ Get custom node fully resizable keeping defined constraints

bool

2.5mm O O 5mm 2.5mm 2.5mm 2.5mm 2.5mm 25mm O 2.5mm 2.5mm 5mm 2.5mm 5mm 5mm 5mm

16

slide-17
SLIDE 17

Contents

I. Context II. Graphical language Definition III. Results

  • IV. Conclusions and future works

17

slide-18
SLIDE 18

Conclusions and Future Works

  • FORM-GL still under development
  • First prototype
  • Sirius provides an environment that links graphical and textual aspects
  • Suggestions:
  • Introduce topological constraints into Sirius and improve Sirius’ ability to bind blocks together
  • Allow editable text field anchoring
  • Facilitate graphical expression so we can represent operating domains defined by equations or points
  • Future work:
  • Grammar refactoring and optimization
  • Model transformation for Modelica
  • Explore model simulation
  • Explore FORM-GL integration to existing languages like SysML
  • Make users able to define their own graphics
  • relations between text and graphic

18

slide-19
SLIDE 19

Temperature t 155 b 295.8 C 30 b 25 b 160 C 70 C 5 b 10 C f1(t, p) f2(t, p) f3(t, p) f4(t, p) ((10.*C ≤ t ≤ 70.*C) and ( 5.*b ≤ p ≤ 30.*b)) or ((70.*C ≤ t ≤ 160.*C) and (25.*b ≤ p ≤ 30.*b)) or ((160.*C ≤ t ≤ 295.8.*C) and (25.*b ≤ p ≤ 155.*b) and (f1(t, p) ≥ 0.) and (f2(t, p) ≤ 0.) and (f3(t, p) ≤ 0.) and (f4(t, p) ≥ 0.)) Pressure p

Charts - Example 1

slide-20
SLIDE 20

Temperature t 140.*b 280.*C 70.*C 60.*C Pressure p 270.*C 135.*b 25.*b 20.*b property p1

during any

3.*h inPDuration < 5.*mn The process can be in this zone, but no more than 5 mn per any time window

  • f 3 hours

Charts - Example 2

slide-21
SLIDE 21

QUESTION S

21

Thank you !!!

slide-22
SLIDE 22

FORM-L

FOrmal Requirements Modeling Language

  • Model envelope of the system
  • Avoid over-constraining

FORM-L main concepts:

  • Variables
  • Events
  • Properties
  • Objects
  • RichEvents
  • Coordination

FORM-L Models:

  • Property model
  • Object model
  • Library
  • Behavioral model
  • Contract model
  • Binding model
  • Configuration Model

22

slide-23
SLIDE 23

Temperature t 140.*b 280.*C 70.*C 60.*C Pressure p 270.*C 135.*b 25.*b 20.*b

Charts - Example 2

slide-24
SLIDE 24

Temperature t 140.*b 280.*C 70.*C 60.*C Pressure p 270.*C 135.*b 25.*b 20.*b The process should remain in this zone

Charts - Example 2

slide-25
SLIDE 25

Charts - Example 3

Voltage v 205.*v 180.*v 170.*v 195.*v property p2 mpsOn When v is greater than 205 v, the MPS should be declared on property p3 mpsOff When v is lower than 170 v, the MPS should be declared off property p1 no mpsOn When v is lower than 195 v, the MPS should not become on property p4 no mpsOff When v is greater than 185 v, the MPS should not become off

slide-26
SLIDE 26

Model-Driven Approach

  • Current process:
  • Textual FORM-L (no FORM-L editor)
  • Validation with simulation tool

→ Stimulus → Mass simulation

  • Verification of scenarios with Modelica
  • Target process:
  • Develop a FORM-GL model
  • Generate FORM-L code
  • Generate entries for Modelica
  • Perform simulation on the generated code, animate the model during

simulation

26

M2: FORM-L Metamodel (FORM-L Grammar) M1: FORM-L Model (FORM-L / FORM-GL models) M0: Real World FORM-GL FORM-L Stimulus Modelica

TRANSFORMATION