Enabling system evolution through configuration management on the hardware/software boundary

Abstract

As the use of software and electronics in modern products is omnipresent and continuously increasing, companies in the embedded systems industry face increasing complexity in controlling and enabling the evolution of their IT-intensive products. Traditionally, product configurations and their updates were managed separately for the hardware and software discipline. At specified release moments during the development of their products, the hardware and software were released together. But, as the usage, flexibility and complexity of software and electronics increases, and fierce competition requires shorter time-to-market and customizable products, more frequent releases of integrated hardware and software configurations becomes necessary. This evolution requires adequate configuration management both within the hard-and software disciplines and across them. In many organizations, software configuration management is more visibly established than hardware configuration management due to the inherent flexibility and complexity of software. But as the flexibility of hardware has increased through the use of configurable hardware, the need for more intense We propose a generic development cycle with real-life examples to illustrate the configuration management concepts. Then, from the sociotechnical design point of view, we raise awareness and argue that configuration management tools, processes, and its organization must be further aligned to support the complexity and interdisciplinary nature of the hardware/software boundary of evolving embedded systems.

Balancing Time‐to‐Market and Quality in Embedded Systems

“…Moreover, not only should the company create and maintain these documents, it should also make sure that the sources are stored properly and remain fully accessible for 15 years. In the regulations documents [Krikhaar et al, ; U.S. Food and Drug Administration (FDA), ], a case is described where a manufacturer did not possess the software source code of a part that behaved erratically in the field. The component supplier had withdrawn without granting the manufacturer the right to access the source code.…”

Managing software development information in global configuration management activities

“…Disciplines: Under the SCM view, the system configuration is composed by CIs that contain software code, as well as items that represent, model, or simulate a piece of hardware (electronic schemas or printed circuit board descriptions). New challenges appear [Krikhaar et al, 2009]: In particular, the integrated hardware/software configurations must be managed carefully, as the two disciplines, which have been traditionally separated, must cooperate closely on a regular base. This requires adequate SCM functionality for storing hardware and software sources, but also for interdisciplinary release management.…”

Modeling the Ripple Effects of IT‐Based Incidents on Interdependent Economic Systems

“…Policies and standards pertaining to IT security, such as ISO 27001 [ISO, ] and NIST Special Publications 800‐series [NIST, ], have grown in importance in the systems engineering community. Furthermore, the relevance of IT and cyber‐security on the systems engineering domain has been underscored in recent publications [see, for examples, Krikhaar et al., ; Bayuk and Horowitz, ]. A vast number of publications on IT security have focused on systems architecting and firm‐level organizational policies; nevertheless, there is also a need to broaden IT security as a macroeconomic systems engineering problem.…”