Integrated Requirements Engineering and Development of ......Data Management, Collaboration, Platform Management, Safety, Change Management Summary Integrated Requirements Engineering:

V1.0 | 2019-10-22

Vector Technology Days 2019

Integrated Requirements Engineering and Development of Specifications

RELEASED

u PREEvision at a Glance

Integrated Requirements Engineering: Integration Levels

Out of The Box Functionalities and Processes

Coordination Process with Internal Experts or External Partners

Agenda

2

Video

PREEvision at a Glance

3

Challenges in E/E Development: Complexity/Capability Gap


Electronic fuel injection

Cruise control

Gearbox control

Traction control

Anti lock brakes


Cruise control

Airbags

Electronic stability control Active body control

Adaptive gearbox control

Adaptive cruise control

Emergency call

Gearbox control

Traction control

Anti lock brakes


Cruise control

Adaptive headlights

Active steering

Curve warning

Stop and Go

Lane keeping assistance

Automated parking

Collision mitigation

Hybrid powertrain

Road trains

Electronic Brake Control Telediagnostics

Car-2-car communication

Software updates

Airbags

Electronic stability control Active body control

Adaptive gearbox control

Adaptive cruise control

Emergency call

Gearbox control

Traction control

Anti lock brakes


Cruise control

u Number and rate of change of functions

u Inappropriate processes and tools

u Number, complexity and interaction of functions

u Increasing authority over control of the vehicle

u Increasing requirements on certification

Hig

h C

ost

Po

or Q

uality

1975 1985 1995 2005 2015

4

Challenges in E/E Development: Complexity/Capability Gap


Hig

h C

ost

Poor

Quality

Hig

h C

ost

Poor

Quality

1975 1985 1995 2005 2015

u Early validation of system concepts based on automated evaluation

u Exchange of concepts with suppliers in early design phases

Q u a l i t y

u Product Line engineering to maximize reuse

u Consideration of the relationships between various views on the system architecture

u Functional, Hardware, Software, Network, Topology, …

C o s t

5

Best-in-Class-Approach means:

u Many interfaces for data exchange

u Customer is system integrator

u Different GUIs

u Complex (multi-site) operation

u No team collaboration support

u Isolated process management data and engineering data

u No (easy) traceability between engineering data

Best in Class Approach vs. Integrated Tool Support


6

Integrated Tool Support means:

u Replacement of many authoring tools

u Model based (all in one) instead of in worst case a document based working with many files

u Common repository, problems like tool borders or broken links simply do not exist. Organization has full overview over the E/E artifacts and their correlations

u Comprehensive data model by well defined language (metamodel)

u Consistent data (correct by construction)

u Bidirectional links

u No redundancy

u Common GUI and Usability

u Seamless traceability

u Reduce costs & faster time to market

Best in Class Approach vs. Integrated Tool Support


All in one

7

Supported E/E Engineering Use Cases


E/E Backbone,Collaboration Platform,

File Management

Design of SafetyRelevant Systems

Product LineEngineering

ArchitectureDesign

Requirements Engineering and Requirements Management

AUTOSARSystem and Software

Design

Communication Design(AUTOSAR and Legacy)

Hardware ComponentDevelopment

Function Driven DesignSystem Design

Test Engineering andTest Management

E/E Backbone,Collaboration Platform,

File Management

Product LineEngineering and Variants

ArchitectureDesign

Requirements Engineering and Requirements Management

AUTOSARSystem, Service and Software

Design

Communication Design(AUTOSAR and Legacy Formats)

Hardware ComponentDevelopment

Function Driven DesignSystem Design

Test Engineering andTest Management

Wiring HarnessDesign

Change and Release Management

Design of SafetyRelevant Systems

8

PREEvision Modeling Layers and Process & Team Support


9

Model Based Development in Large Groups


u Multi User – Single Source→ Multiple users work collaboratively, supported by Lock&Commit, Life Cycles, Rights&Role Management and Ticket System

u Multiple projects are handled in one system, supported by ProductlineManagement, Variant Management

u Import and export with industry standard exchange formats (AUTOSAR, DBC, LDF, FIBEX, RIF, ReqIF, KBL, CSV)

Chief Architect

Req.-Engineer

FunctionDesigner

SoftwareDesigner

NetworkDesigner

WHEngineer

ComponentDesigner

Safety Engineer

ProjectManager

TestManager

TestEngineer

Model-Data

10

Model Based Development – Single Point of Truth


SW

Arc

hitectu

reu Domain specific language and data model

u Single source model across all Automotive E/E development Use Cases:→ The model is the Single Point of Truth→ Mappings ensure full traceability→ The model can be analyzed by metrics

u All data objects have a semantic meaning→ Base for various model checks e.g. for

Correctness, Completeness, Consistency

u Automated algorithms for synthetization, scheduling, signal routing, etc.

PowerMirrorCtrl

Type: PowerMirrorCtrl

SwitchMatrix

Type: SwitchMatrix

PowerMirrorPass

Type: PowerMirr...

PowerMirrorDriver

Type: PowerMirr...

PowerManagement

Type: PowerMan...

x+:pm_pass_x+

y+:pm_pass_y+

y-:pm_pass_y-

x-:pm_pass_x-

y+:pm_driv_y+

x+:pm_driv_x+

y-:pm_driv_y-

x-:pm_driv_x-

y:PM_y

x:PM_x

sel:PM_selection

def12:KeyIn

sel:PM_selection

x:PM_x

y:PM_y x+:pm_pass_x+

y+:pm_pass_y+

y-:pm_pass_y-

x-:pm_pass_x-

y+:pm_driv_y+

x+:pm_driv_x+

y-:pm_driv_y-

x-:pm_driv_x-

KeyIn:KeyIn Assembly Net

Assembly Net

Require-

ments

Netw

ork

/HW

Arc

hitectu

reW

irin

g/

Geom

etr

y

Body Ctrl

Driver Door CtrlPass Door Ctrl

Gateway

SwtichMatrix

PassengerMirror DriverMirror

BatMng

-

-

-

-

-

-

-

-

-

DoorLIN:LIN

Ground

PowerSupply

- cv2:4w -KA_Pass Door Ctrl _0

-

-

CANPT:CANC

Logic

al

Arc

hitectu

re

11


u Integrated Requirements Engineering: Integration Levels



Agenda

12

Evolution of Requirement Engineering Tools


File based

Purely textual

No Traceability

Standalone Tool

Structured Requirements

Internal Linking & Tracing

Linking to other tools or databases not reliable and not possible on atomic basis

Tool Environment

Linking & Tracing to e.g. Test tools

Integration via OLSC possible but relations across database boundaries cannot be versioned and archived.

Fully Integrated

Common database allows links on atomic basis

No tool borders

Versionable and reliable

Consistent traceability

File based, only lightly

coupled

13

Level 1: Purely Textual


Purely textual in PREEvision?

u Model based

Purely textual

14




u Model based

u Formulized language for describing data (Metamodel), information is clear, structured and consistent

u Different Requirement Types (Definition, Information, …)

Purely textual

15



16




u Model based

u Formulized language for describing data (Metamodel), information is clear, structured and consistent

u Different Requirement Types (Definition, Information, …)

u Consistency and Online Checks

u Lifecycles

u Version Management

u Reuses

u Roles and Rights Management

u LibO Formatting & Reporting

u Use Case Diagrams

Purely textual

17

Level 2: Usage of Requirements Links


Link requirements among each other

u Different Link Types (trace, refine,…)

u Better Traceability

u Better Understanding

Requirement Links

Purely textual

Natural border of standalone tools

18

Level 3: Usage of Mappings


Purely textual

Requirement Links

Mappings

Linking the Model

u Type safe

u Basis for analysis, e.g. coverage analysis

u Consistent traceability through the model

u Simple navigation

u Simplification of understanding, e.g. by usage in diagrams

u Easy creation via drag&drop in Model View,diagrams or in Table Editors

19

Level 3: Usage of Mappings


20

Level 4: Usage of Variants


Purely textual

Requirement Links

Variants

Mappings

Make it context dependent

u Determine variants, e.g. relevant series for a requirement directly in the Requirement Text Editor

21



22



Purely textual

Requirement Links

Variants

Mappings

Make it context dependent

u Determine variants, e.g. relevant series for a requirement directly in the Requirement Text Editor

u No need to create an independent requirement for each variant as information is separated

u Activation of a variant highlights requirements associated to the variant in the specification editor

u Generation of variant sensitive reports and specifications

23

Level 5: Usage of Placeholders


Purely textual

Requirement Links

Variants

Mappings

Placeholder

Reference the model

u Referencing of any attribute of any artifact in the model via drag&drop into a rich text.

u Referencing of diagrams, charts and tables

u Placeholders are kept always up to date

u Relevant attributes can be defined for a perspective

u Copy and paste support with automatic mergeof already existing placeholders

u Change marker indication if placeholdercontent has been changed

24

u Referencing any attribute of any artifact in the model via drag&drop into a rich text.

u DnD support from Model View, Tables and Diagrams

u Changed placeholder content can be identifiedvia change marker indication in front of the referenced attribute:

Indication of change marker is propagated additionally in

u Containing attribute (e.g. description)

u Table Editors

u ModelView

u Property Editor

Level 5: Usage of Placeholders


25

Level 6: PREEvision


Purely textual

Requirement Links

Variants

Mappings

Placeholder

Model is the specification

The model is the requirement specification

u Get along without requirement artifacts at all – use instead the model as single point of truth!

u Via the ReqIF Export any artifact with any attribute from any layer can be used for the specification document.

Goal might not be completely reachable due to standards, laws, company internal or non functional requirements used in the specification

26


27

Data Management, Collaboration, Platform Management, Safety, Change Management

Summary


Requirements Engineering and Management

Test Engineering and Management

FunctionalArchitectureDesign

SOADesign

SoftwareDesign

PhysicalArchitectureEvaluation

PhysicalArchitectureDesign

PhysicalSystemDesign

COMDesign

WH SeriesDesign

WHArchitectureDesign

REQ-X Mapping

Subject under TestSpecified Artifact under Test

28



u Out of The Box Functionalities and Processes


Agenda

29

Data Management, Collaboration, Platform Management, Safety, Change Management

Processes


Requirements Engineering and Management

Test Engineering and Management

Specification of Tests

Design & Implementationof Tests

Execution & Documentationof Tests

Evaluation & Analysisof Test Results

Planningof Tests

Template Definition

Agreementwith Supplier

System Specification

Component Specification

30

Test Engineering: Process, Roles and Import & Export Interfaces


Specification of Tests

Design & Implementationof Tests

Execution & Documentationof Tests

Test Planning & Tasks

Evaluation & Analysis of Test Results

Requirements Test Analysis

ReportReport

Report

Planningof Tests

Execute

Requirements Engineer

TestManager

TestManager

Test Implementation

Manual test sequence

Test script

TestEngineer

Test Execution

Verdict

ar

Verdict

ar

Test Specification

TestEngineer

Library

Reuse

TestEngineer

SpecificationHeading

ItemItem Step

AnalyzeDerive

Synthesis

Create PlanTest

Test Execution Tool

Vector CANoe3rd party

Parse for Verdicts andRequirements / Test Specification Associations

Test Design & Implementation Tool

Vector vTESTstudio3rd party

SynchronizeTest Scripts

Traceability Information

Requirements Source

RIF, ReqIFXLS

Import & Update

TestItemsSource

ReqIF

31

Requirements Management: Involved Roles

Out of The Box Functionalities and ProcessesLegend:

Responsible Role

Supporting Role

Component Responsible

System Responsible

Test Engineer

Architect

32

Component specification

B


A

Integrated Requirements Process


Template

V1

System specification

Instantiation

Reuse & Copy

Attributes

Structure

Syste

m a

nd C

om

ponent

Tem

pla

te

V1

V1 V1

PL PL PL PL

33



Template System specification


AV1 V1

V1


B

V1

Instantiation

System provides content

Reuse & CheckinLinking between Component and

System

Reuse & Copy

Attributes

Structure

PL PL PL PL

34

Version management


35





AV1 V1

V1


B

V1

V2

V2

Merge & Updatekeep links

Instantiation


Reuse & CheckinLinking between Component and

System

Reuse & Copy

Attributes

Structure

Changes

36

Merge


37

The Merge Block introduced with PREEvision 8.5 can be used for an automatic merge of 2 artifacts of the same Meta Class. Merge options are available in Merge Block:

u Identity allows to define if either the source or the target artifact shall keep their identity

u Priority defines if either the data of the source or of the target artifact shall have priority in case of conflicts. With “Replace” all data of the source is taken over and the data of the target is discarded.

Merge Automation


38





AV1 V1

V1


B

V1

V2

V2

Instantiation

Reuse & Copy

Attributes

Structure

Changes

Merge & Updatekeep links

? Change details

set Lifecycle State

39

u Recognition of an changed artifact either by

u revision number of an updated requirement or a

u lifecycle state or by

u change marker symbol (Model View, Table Editor or Property Editor)

u Change details for an artifact can be accessed on level of attribute changes in the Change History View

Change Management


V2

? Change details

40

Change Logs

Support for recording, analysis and display of relevant changes

u Changes are documented via a ticket

u Relevant changes can be defined by profiles (Meta Classes and Meta Attributes)

u On commit of an relevant artifact a ticket can be selected, the changed artifacts are associated, change log is created

u Change History allows to view the recorded changes regarding

u change interval

u relevant attributes

u Change logs can be accessed and can be displayed in Table Editors for showing relevant changes (from viewpoint of change order and viewpoint of changed artifact)

Change Management


Deliver relevant change details tocollogues or suppliers

41

Lifetime of specifications


Specification versions

Released Specification

V1 V3 V4

Test Engineer Component Responsible

Suppliers

In t

est

V2

In w

ork

In a

gre

em

ent

42




u Coordination Process with Internal Experts or External Partners

Agenda

43

Review & Vote


System specification


A

V1

V1


V2

V2


Changes

Component A

V2

Supplier


Agreements by votingbetween OEM and

Supplier(s)

Component A

V2


System Responsible

Internal Review

44

Review and Vote


uReview

u Participants

u Artifacts to review

u Evaluation by comments

u Comment and Chat View

Vote

u Participants

u Artifacts to review

u Voting type

u Majority vote

u Consensuses vote

u Mandatory or optional vote

u Voting result analysis

Combination of Review & Vote is also possible for an internal review

45

u Review instantiation via wizard

u Personal Task Tables for Review participants

Review specifications



System Responsible

Task Overview Table

Agreement Task: System 1

Agreement Task: Component 4


Task Overview Table


Agreement Task System 1

Agreement Task System 146

Agreement Export via

Agreements between OEM and Suppliers


Export the Specificationprepared for review

OEM

Initiate Review

OEM

Spec

Supplier

Component 2

SPEC

The ReqIF Agreement Export puts all the relevant information in one ReqIF file.

u E.g. the Requirements Specification, where you have initiated the „Specification Review“.

u The information about the provided status.

u The agreement information for the review.

47

Agreement Export via

Agreements between OEM and Suppliers


Initiate Review

OEM


OEM

Spec Review

Supplier add his comments and set his status e.g. in 3rd party tool

Supplier

Spec

Supplier

Component 2

SPEC

Import ReqIF filewith review content

OEM

Agreement Import via

Only Supplier Statusand Comments are imported

OEM

Component 2

SPEC

OEM can perform an assessment in PREEvision of the feedback given by the supplier

48

Exchange of Agreements between OEM and Supplier via ReqIF


Only export supported

49

Small Example


Initiate Review

OEM


OEM

Spec Review

Supplier

Spec Import ReqIF filewith review content

OEM

50

© 2019. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2019-10-22

Author:Robert RotterVector Germany

For more information about Vectorand our products please visit

www.vector.com

http://www.vector.com/

Documents

Integrated Requirements Engineering and Development of ......Data Management, Collaboration, Platform Management, Safety, Change Management Summary Integrated Requirements Engineering: