ibm innovate-2014 #2478-hammel_pub

Internal | CDG-SMT/EMT | 4/12/2014 | © Robert Bosch GmbH 2014. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.

IBM Innovate 2014 Conference

Cross Divisional Group - Software, Methods and Tools1

#2478Collaborative Automotive Software EngineeringChristof Hammel Raz YerushalmiBosch, Germany IBM, Israel

https://www.flickr.com/photos/orinrobertjohn/2506190082

https://www.flickr.com/photos/orinrobertjohn/2506190082


IBM Innovate 2014

Cross Divisional Group - Software, Methods and Tools

Part 1: Automotive Systems & Tools

Introduction

Automotive domain: Product evolution & trends

IT domain: Tool evolution & trends

SW-Engineering: Architecture – Organization – Tools

Part 2: Show case – Collaboration & Compliance by Tools

Outline


IBM Innovate 2014

Cross Divisional Group - Software, Methods and Tools3

Introduction


IBM Innovate 2014


My home

https://maps.google.com/

https://maps.google.com/

IBM Innovate 2014



My home

Silo



Car MultimediaInstrumentation

Systems

Navigation andInfotainment

AutomotiveDomain

BodyParking-Systems

El.-EnergyManagement

Body-Computer

VehicleSecurity

Powertrain Chassis

Brake-Control

Occupant-Systems

Driver-Assistance

Transmission E-Motor

Diesel Gasoline


IBM Innovate 2014


Automotive System Evolution

1927In-line pump(only mechanical)

19861st EDC(Electronic Control Unit without software)

19971st CommonRail(software as integral part in of the system)

2006Software as KeyCompetence

Subsystems evolved locally


IBM Innovate 2014


Silo’d Automotive Systems

Powertrain Chassis MultimediaBody


IBM Innovate 2014

Cross Divisional Group - Software, Methods and ToolsChassis MultimediaBody

“Connected” Automotive Systems

Powertrain



Automotive Software Architecture

C1 C2

C2


IBM Innovate 2014


Silo’d Tools

RequirementsDevelopment

SoftwareDevelopment

ConfigurationManagement

TestManagement

ChangeManagement


IBM Innovate 2014

Cross Divisional Group - Software, Methods and ToolsRequirementsDevelopment

SoftwareDevelopment


TestManagement

ChangeManagement

“Connected” Tools


IBM Innovate 2014


{ System x Tool } Silos

Non-Collaborative


IBM Innovate 2014

Cross Divisional Group - Software, Methods and Toolshttps://www.flickr.com/photos/husseinabdallah/4629112185

Silo Engineering

https://www.flickr.com/photos/husseinabdallah/4629112185


IBM Innovate 2014


Automotive TrendsAutomated Driving

Connected Vehicle (Car-2-X, IOT)

Electrified Mobility


IBM Innovate 2014


We need...More than just “connected” systems

Integrated systems Big Data systems faster innovating systems

More than just “connected” tools Integrated & interoperable tools Collaborative & Agile supportive tools Efficiency, Quality & Compliance by tools

Collaboration across Roles (Management / Engineering / Quality) Automotive domains Companies (OEM / Supplier / 3rd Party / IT / Web / BigData)


IBM Innovate 2014


“Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.”

(Melvin Conway)

OrganizationArchitecture

Conway - Law

Conway -1 - Law

Organization, ProcessBehavior

Hammel - Law

Hammel -1 - LawTools

“Tools which are used by organizations… are constrained to shape the organization and its behavior according to the paradigms of these tools.”

(Christof Hammel)


IBM Innovate 2014


OrganizationConway -1 - Law

Organization, ProcessBehavior

Hammel -1 - LawTools

Architecture


IBM Innovate 2014


New System Architecture Open Integration platform Standardized interfaces

Transferability of components

AUTOSAR


IBM Innovate 2014

Cross Divisional Group - Software, Methods and ToolsRequirementsDevelopment

SoftwareDevelopment


TestManagement

ChangeManagement

Coupling / Sync

Develop Requirements Manage Project Develop Software Test

New Tool Architecture



Tool Integration Services (TIS)

Appl. Server’s

WebClient

Auto-IWG Eclipse

UBK Common Eclipse Platform

CDT

oAW

Perl Authorin

g Config. Validation

View,Navigate

,Search

Build

ALMPlugIn

s

Req CRQ SCM

Cont.-Int.

Eclipse-Client (SW-Development)Non-Eclipse-Clients

Design

MBD

ALM-Coupling

Collaborative Engineering Env.

Wiki

E 2.0

ALM

TestM

Appl. Server’s

Req CRQ SCM TestM



Inter-Company collaborationOEM

.aar

Auto-IWG Eclipse

Applications

Automotive Domain Object ModelsBDOM, Artop

Metadata Framework

BuildFramework

ALMPlugIns


IBM Innovate 2014


IBM Innovate 2014Traceability

It's not that the brakes don't work, it's the traceability of the software.

“ “Pat Shanahan,

General Manager, 787 Project



Collaboration by TraceabilityRequirements Design

CodeTest Case



SPICE – Processes



Primary Life Cycle Processes

Engineering Process Group

ENG.2 System requirements analysisENG.3 System architectural designENG.4 Software requirements analysisENG.5 Software designENG.6 Software constructionENG.7 Software integrationENG.8 Software testingENG.9 System integrationENG.10 System testing

Supporting Life Cycle Processes

Support Process Group

SUP.1 Quality assuranceSUP.8 Configuration managementSUP.9 Problem resolution managementSUP.10 Change request management

Organizational Life Cycle Processes

Management Process Group

MAN.3 Project managementAcquisition Process Group

ACQ.4 Supplier Monitoring(optional)

Automotive SPICE – ProcessesHIS Scope (Basically German OEM’s)



ENG. 2: System requirements analysis1) a defined set of system requirements is

established;2) system requirements are categorized and analyzed

for correctness and testability;3) the impact of the system requirements on the

operating environment is evaluated;4) prioritization for implementing the system

requirements is defined; 5) the system requirements are approved and

updated as needed;6) consistency and bilateral traceability are

established between customer requirements and system requirements;

7) changes to the customer’s requirements baseline are evaluated for cost, schedule and technical impact;

8) the system requirements are communicated to all affected parties and baselined.

ENG. 3: System architectural design1) a system architecture design is defined that

identifies the elements of the system and meets the defined systems requirements;

2) the system requirements are allocated to the elements of the system;

3) internal and external interfaces of each system element are defined;

4) verification between the system requirements and the system architecture design is performed;

5) consistency and bilateral traceability are established between system requirements and system architectural design;

6) the system requirements, the system architecture design, and their

relationships are baselined and communicated to all affected parties.



ENG. 4: Software requirements analysis1) the software requirements to be allocated to the

software elements of the system and their interfaces are defined;

2) software requirements are categorized and analyzed for

correctness and testability;3) the impact of software requirements on the

operating environment is evaluated;4) prioritization for implementing the software

requirements is defined;5) the software requirements are approved and

updated as needed;6) consistency and bilateral traceability are

established between system requirements and software requirements; and consistency and bilateral traceability are established between system architectural design and software requirements;

7) changes to the software requirements are evaluated for cost, schedule and technical impact;

8) the software requirements are baselined and communicated to all affected parties.

ENG. 5: Software design1) a software architectural design is defined that

identifies thecomponents of the software and meets the defined

softwarerequirements;2) the software requirements are allocated to the

elements of the software;3) internal and external interfaces of each software

component are defined;4) the dynamic behaviour and resource consumption

objectives of the software components are defined;5) a detailed design is developed that describes

software units that can be implemented and tested;

6) consistency and bilateral traceability are established between software requirements and software architectural design;

7) consistency and bilateral traceability are established between software architectural design and software detailed design.



ENG. 6: Software construction1) a unit verification strategy is defined;2) software units defined by the software design are

produced;3) consistency and bilateral traceability are

established between software detailed design and software units;

4) software units are verified according to the unit verification strategy;

5) results of unit verification are recorded.

ENG. 7: Software integration test1) a software integration and integration test strategy

is developed for software items consistent with the software design according to the priorities and categorization of the software requirements;

2) a test specification software integration is developed that ensures compliance with the software architectural design, software detailed design, allocated to the items;

3) software units and software items are integrated as defined by the integration strategy;

4) integrated software items are verified using the test cases;

5) results of software integration testing are recorded;

6) consistency and bilateral traceability are established between software architectural design and software detailed design to software integration test specification including test cases;

7) a regression strategy is developed and applied for re-integrating and re-verifying software items when a change in software items (including associated requirements, design and code) occurs.



Key points across the process Following “best practice” implementation Requires traceability between versioned artifacts

Consistency and bilateral traceability



Added tools to define and manage traceability between versioned artifacts:

Validity Editor The Validity Editor is provided for a RTC Component, allowing

review, edit and summary info regarding associations and validity of files belonging to that Component. It also support reporting of the summary info.

Associations Editor The Associations Editor is provided for a File (in the repository),

allowing the definition of associated (repository) files for a given Association Type.

RTC Workitem Extension The RTC WI (Task) extension support updating of validity

information related to files in change-sets linked with a given Task.

Overview of the capabilities:



Validity Editor



Associations Editor



Thank You!

Your Feedback is Important!

Access the Innovate agenda tool to complete your session surveys from your smartphone, laptop or

conference kiosk.

ibm innovate-2014 #2478-hammel_pub

Technology