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 Wegerson
Bloomington, Minnesota USA

08 Nov 2007 Copyright 2007 Patrick Wegerson - All Rights Reserved2
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
Schedule
Savings
Cost
Savings

Agenda
 Introduction
 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
 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 CI
Mechanical
(Hardware) CI
Electronic
(Hardware) CI
Software CI
Component S1
Software CI
Component S2
Mechanical CI
Component M1
Mechanical CI
Component M2
Electronic CI
Component E1
Electronic CI
Component E2
Firmware CI
Component F1

Systems Object Hierarchy (OO-CM)
Systems CI
S-Module CI M-Module CI E-Module CI
CI Component
S1
CI
Component S2
CI Component
M1
CI Component
M2
CI Component
E1
CI Component
E2
CI Component
F1

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
 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 Configuration
Control 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
Hardware
Software
-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
 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
 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 Wegerson
Bloomington, Minnesota USA
Phone: 952-921-6994
Email: patrick.wegerson@gd-ais.com

Configuration Management for Embedded Systems

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Configuration Management for Embedded Systems

Ähnlich wie Configuration Management for Embedded Systems (20)

Mehr von elliando dias

Mehr von elliando dias (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Configuration Management for Embedded Systems