configuration management for embedded systems

08 Nov 2007 Copyright 2007 Patrick Wegerson - All Rights Reserved 1

Configuration Management for Embedded Systems

Software and the “Hard” Stuff

Patrick WegersonBloomington, Minnesota USA


Presentation Objectives

To Compare Software and Hardware Configuration Management (CM)

To Describe the Challenges of Systems (not just Software) CM

To Describe Best Practices of Embedded Systems CM

To Answer Your Questions To Enjoy the Presentation!


Agenda

Introduction

Compare Software CM to Hardware CM

Systems CM Overview

Systems CM Best Practices

Summary

References


Introduction

Who: Your Presenter What: Effectively integrating

Hardware CM with Software CM to create System CM

Why: Embedded Systems development works better when supported by System CM

Where and When: Here and Now!


Traditional CM versus Integration

Software Configuration

Hardware Configuration

Integration –

Systems Configuration

Lifecycle Time


Preferred CM versus Integration

Software Configuration

Hardware Configuration Integration –

Systems Configuration

Lifecycle Time

ScheduleSavings

CostSavings


Agenda

Introduction


Systems CM Overview


Summary

References


Hardware Configuration Management

Developed from military and aerospace systems experience

Nearly 50 years of experience (as a defined support process)

Numerous supporting tools available Standardized practices across

differing industries Only sometimes integrated with

hardware development tools


Hardware CM Processes

Well established and consistent Hardware CM processes, such as Design Release to Production Hardware Baselines Engineering Change Proposal (ECP)

Hardware CM processes coupled to Hardware release tools (i.e. ERP, MRP) External interface requirements, such

as suppliers or manufacturer


Software Configuration Management

Based on Hardware CM principles Nearly 30 years of experience (as

an explicit knowledge area) Numerous support tools available More variety of processes than

Hardware CM Usually integrated with software

development tools


Software CM Processes

Practices have evolved over time, though principles remain constant: Identification, Control,

Status Accounting, Audit (Verification) Planning added with ISO 10007 Software CM processes coupled to

Full Lifecycle development tools Internal interface requirements, such as

traceability and flexibility Problem Reports & Configuration Control

Boards (CCBs) early in lifecycle


Agenda

Introduction


Systems CM Overview


Summary

References


Systems CM Overview

“Begin with the end in mind” Fully integrated embedded system Efficient use of resources, cost and

schedule Effective product development processes

Project management is equivalent across hardware and software

CM complements project management Project management drives to results CM accurately records what resulted


Systems CM Challenges

Why are Hardware CM and Software CM treated so differently?

Are there major differences between Hardware CM and Software CM?

How are Hardware CM and Software CM similar?

How can Hardware CM and Software CM be better aligned and integrated?


Systems CM Planning

“Plan CM Work, Work the CM Plan” Plan for integrated CM through

Processes selected or defined Tools selected and used One comprehensive (Systems) CM Plan Hierarchy of Configuration Control Boards

(SE/SW/HW) Best if supported by organizational CM

processes and tools Iterative (on-going) CM planning Resources need to be assigned


Systems CM Identification

Baselines include software and hardware configuration items (CI)

Software CI and Hardware CI use consistent identification scheme Same CM Identification “language”

regardless of hardware or software Includes identifying components,

baselines, versions, etc. Reduces defects / simplifies auditing


Systems Architecture Hierarchy

Systems CI

Software CIMechanical

(Hardware) CIElectronic

(Hardware) CI

Software CIComponent S1

Software CIComponent S2

Mechanical CI Component M1

Mechanical CI Component M2

Electronic CIComponent E1

Electronic CIComponent E2

Firmware CIComponent F1


Systems Object Hierarchy (OO-CM)

Systems CI

S-Module CI M-Module CI E-Module CI

CI ComponentS1

CIComponent S2

CI ComponentM1

CI ComponentM2

CI ComponentE1

CI ComponentE2

CI ComponentF1


Systems CM Control

Use same tools for tracking hardware or software change proposals

Change impact must consider effects on both hardware and software CI

Hierarchy of Configuration Control Boards (CCBs or ISO 10007 “dispositioning authority”)


Systems CM Status Accounting

Best generated from an automated configuration information system

Should tailor CM status reports to a specific audience, such as hardware

Essential for current traceability of the complete system

Data retention, security, recovery are critical product configuration data


Systems CM Audit (Verification)

Should involve Quality Assurance for more objective evaluation

Should use auditors that understand hardware, software, and systems

Best done at formal baselines, especially early in lifecycle

Don’t discount this activity; CM defects can invalidate product tests!


Traditional CCB Structure

Product Configuration

Control Board (CCB)

or

Software Configuration Control

Board (SCCB)

Hardware Configuration Control

Board (HCCB)


Agenda

Introduction


Systems CM Overview


Summary

References


Systems CM Best Practices -1

Multi-level Configuration Control Boards (CCBs)

Systems CCB is top-level Sub-levels are Software CCB and

Hardware CCB Architecture and Communication are

critical for success Empower CM staff as CM Engineers


Preferred CCB Structure

System ConfigurationControl Board (CCB)

Software CCB Hardware CCB

Firmware CCB


Systems CM Best Practices - 2

Integrated or Same CM Tools for Software and Hardware

Can baseline software and hardware components with similar / same tool

Better full-lifecycle configuration management and support

All CM activities use centralized data Fewer (CM) tools to maintain



Equivalent Software CM and Hardware CM Processes

Capability Maturity Model® Integration for Development, Ver. 1.2

Key standards don’t differentiate Software CM from Hardware CM ISO 9001, ISO 10007, EIA-649-A (USA Std.)

Improves cross-functional (software – hardware) communication



System Configuration Matrices Document compatible hardware and

software versions Proactively plan supported product

configurations Good summary of Status Accounting

and useful for Auditing / Verification


Configuration Matrix Example

HardwareSoftware

-01 -02 -03 -04

1.0 X

1.1 X

1.2 X X

2.0 X X

2.1 X X X

3.0 X X X

3.1 X X X


Agenda

Introduction


Systems CM Overview


Summary

References


Summary

Software CM is not fundamentally different than Hardware CM

Minimize Software CM and Hardware CM process and tool differences

Align and integrate Software CM and Hardware CM into Systems CM to achieve real business benefit

Treat CM as a vital foundation for world-class software and systems


Agenda

Introduction


Systems CM Overview


Summary

References


Presentation References

ISO 10007:2003(E) “Quality Management Systems – Guidelines for Configuration Management”

ANSI/EIA-649-A 2004 “National Consensus Standard for Configuration Management”

Bersoff, Edward et. al., “Software Configuration Management – An Investment in Product Integrity”, Prentice-Hall, 1980, ISBN 0-13-821769-6

CMMI for Development, Version 1.2 (CMU/SEI-2006-TR-008, ESC-TR-2006-08). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, August 2006


“Take-Away” References

CM Crossroads: www.cmcrossroads.com Institute of Configuration Management: www.icmhq.com Data & Analysis Center for Software (DACS):

https://www.thedacs.com/databases/url/key.php?keycode=2920

Quality Resources On-Line CM Resource Guide: http://www.quality.org/config/cmresourceguidemaster.txt

Software Engineering Institute – Capability Maturity Model® Integration (CMMI®) for Development Ver. 1.2 http://www.sei.cmu.edu/cmmi/


Presenter Vitae

Patrick WegersonBloomington, Minnesota USAPhone: 952-921-6994Email: [email protected]

configuration management for embedded systems

Technology

embedded systems software

consistent hardware

systems ci smodule ci

tracking hardware

hardware essential

hardware development

overview systems

hardware release tools