Configuration Management for Embedded Systems

Configuration Management for Embedded Systems Software and the “Hard” Stuff Patrick Wegerson Bloomington, 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 Schedule Savings Cost Savings

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 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
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 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 X X X 3.1 X X X 3.0 X X X 2.1 X X 2.0 X X 1.2 X 1.1 X 1.0 -04 -03 -02 -01 Hardware Software

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 Wegerson
Bloomington, Minnesota USA
Phone: 952-921-6994
Email: [email_address]

Configuration Management for Embedded Systems

by elliando dias on Dec 29, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 5

Statistics

Configuration Management for Embedded Systems — Presentation Transcript