Application Lifecycle Management in Embedded Systems Engineering
Today’s embedded systems are complex and widespread. According to the Automotive Open System Architecture (AUTOSAR) consortium, today’s modern cars can have up to 70 electronic control units. Embedded software is the integration technology of choice, and often the differentiator for a product. Embedded systems are often produced in large volumes, and the embedded nature of the software can make it difficult to update once the product is deployed. The cost of finding and fixing defects grows exponentially for embedded systems as such corrections happen later in the development cycle. Also, embedded systems often play critical roles, where software failure can result in expensive damage to equipment or injury or death. For these reasons embedded systems are typically put through more rigorous validation processes and held to higher quality standards than most desktop computer applications. Finally, given the real-time, event-driven nature of most embedded systems and the fixed system resources available, embedded systems engineering is much more challenging than ordinary software development. I never had to do rate monotonic analysis for a server application, or a failure modes, effects and criticality analysis for the desktop applications I wrote, but I have done both for embedded systems projects.
Requirements Management
Given how critical it is that embedded systems perform properly, requirements definition and management is one of the most critical disciplines in ALM. If you don’t have well defined, verifiable requirements, you have no chance of delivering a successful product. Many industries that work with embedded systems such as automotive, aerospace and telecommunications have recognised the importance of requirements management and mandate that a well defined requirements management process, automated where possible using requirements management tools, be in place. ALM places emphasis on requirements definition, requirements traceability, and the participation of requirements in the change management process.
Requirements definition has traditionally been done by analysts and system engineers in the form of structured documents or spreadsheets. Once defined and agreed upon, requirements need to be communicated to all the members of the development team, and the monolithic document format is not always the best for consumers of requirements. A mature ALM implementation will make use of a requirements management tool that both supports the definition of requirements in a document form, and the viewing of requirements either individually or as sections of the larger document.
Requirements traceability is necessary to ensure that the requirements are properly implemented and can be verified and validated. Traces need to be visible between requirements and all downstream activities and resulting artifacts, including designs, models, source code artifacts, test cases, defect reports and deliverable build artifacts. Traces also need to be actively managed, so that as requirements change, or new downstream artifacts are generated, the traceability across the lifecycle is maintained. Traceability used to be maintained manually, with junior system engineers being tasked with the creation of large traceability matrix documents. Typically this was done either just prior to milestone review meetings (if the project manager was proactive) or done just prior to delivery (if the project was running late). Either way the result was not that useful or accurate. Good ALM tools automate the capture of requirements and the maintaining of traces between requirements and the downstream activities and artifacts produced, and the relationships are bi-directional; they should allow for top-down or bottom-up tracing. The ALM tool or tools also need to incorporate rigorous change management.
Change Management
Change is inevitable, and if you do not have a process in place to manage it, it will manage you. The Waterfall lifecycle model assumed that change was not a significant factor in the development lifecycle, and history has shown that assumption to be false in most cases. That is why today’s modern software lifecycle standards such as ISO 12207 do not mandate a specific lifecycle, and why quality standards such as the automotive industry’s TS-16949 (formerly QS9000) mandate a closed loop change management system. Change always occurs in a context, and with ALM that context is the set of requirements for the system being developed.
ALM requires a well defined change management process to be implemented, which supports the definition of change requests, their association with the artifacts that are the intent of the change, with each change request being reviewed and approved or rejected. The traceability support provided by the ALM toolset is critical during the change request review, since typically impact analysis is a major factor in the approval decision. For example, on June 4, 1996, the ARIANE 501 satellite launch failed catastrophically immediately after launch, with a direct cost in terms of lost payload of approximately $370 million. Subsequent analysis indicated that inappropriate re-use of a flight control system designed for an earlier model ARIANE launch vehicle was the root cause of the failure. The changes to the requirements for the newer generation launch vehicle were not adequately traced to the components planned for re-use, and the proper impact analysis was not performed.
Change management should be automated as much as possible by the ALM tools. The specific workflow and approval procedure for change requests will depend on your organisation’s corporate processes, the lifecycle model you adopt, and the level of rigor required by your customers. For those reasons, look for an ALM tool that supports easy configuration and updating of workflow, and can implement different workflows for different projects if necessary. Also remember that your process definitions themselves should be put through the change management process; for organisations following a process improvement model such as the CMMI for Development from the Software Engineering Institute (SEI) or Six Sigma, a key principle is continual refinement and improvement of processes and practices. Ideally the ALM tool you use to implement workflow and process automation should maintain a history of changes to the process definitions, and allow automated deployment of approved changes to process from a test environment to the production server, so that process changes are controlled the same way development changes are.
Configuration Management and Re-Use
Configuration management and support for re-use of assets is critical for all the artifacts of the application lifecycle. Embedded systems can contain millions of lines of code, executing on multiple processors; their development can involve hundreds of individuals. Such complex configurations require robust configuration management, and this too should be automated as much as possible. The ALM tool that implements your configuration management should support the definition and manipulation of complex configurations, and provide proper support for versioning, branching and sharing of these configurations.
A number of studies have shown that product lifecycles are getting shorter, while at the same time service life times are lengthening. A U.S. Military study identified that commercial integrated circuit product lifecycles were decreasing to a 2 – 4 year range, while the aerospace industry assumes the life of a line replaceable unit is greater than 10 years . More and more companies are adopting management approaches along the lines of the SEI’s Software Product Lines approach, which involves producing a set of systems that share a common, managed set of features and are developed from a common set of core assets. Asset re-use is key to implementing such an approach. Effective asset re-use requires the configuration management system to support configuration sharing. With Software Product Line asset re-use, it requires that the ALM toolset provide robust configuration management support for all the artifacts in the lifecycle, not just the source code artifacts. Sets of requirements are configurations, as are test suites and use cases – they should also be versioned and when a component is re-used in another project, all its associated artifacts (requirements, designs, test cases, and source) should be shared, with the traces between artifacts maintained. Parallel development is best supported by branching at the configuration level, rather than just branching at the individual file level.
The configuration management system must also tie into the change management process as seamlessly as possible. It is the configuration management system that enforces the change control constraints of the change management process. Developers should make updates only based on approved change requests, otherwise there is no project management insight into the development, and significant chance that what is developed does not match what was agreed upon. Next, testers should only work on approved and properly versioned configurations obtained directly from the CM repository. Naturally, test artifacts such as test cases, test suite execution records, and defect records should also be under configuration management control and related to the implementation artifacts being verified and the requirements that they are being verified against. This tight interconnectedness of artifacts is best achieved by minimising the number of ALM artifact repositories; ideally your ALM toolset should work with a single common repository.
Distributed Development Support
Many embedded system products need to be cost competitive; most of the major automobile manufacturers impose cost reduction programs on their major suppliers, for instance. In addition, some products have a limited product life, so time to market can significantly impact profitability. Thus many embedded systems providers are moving to globally distributed development. By taking a globally distributed approach they can go where scarce talent is available, source development resources at the most competitive labour rates, and implement “follow the sun” development cycles. By handing off work from one site to another as the various working days end, companies can get multiple man-days of work implemented within one calendar day – reducing the time to market.
However, geographically distributed development introduces communication and coordination challenges. One way to mitigate such challenges is to have well defined and enforced processes, so that activities are recorded in a central repository that all users have access to. Partitioning the work so that the coupling between different geographic sites is minimised is another way to reduce the risk associated with geographically distributed development. The ALM toolset used to control access to the artifacts and implement the work processes should provide realtime status on changes and task assignments to all users, regardless of where they are located. The ALM toolset should also mitigate the performance impacts of limited bandwidth or high latency network connections, so that performance is acceptable whether working at the main site or a remote site.
Metrics, Analytics and Reporting
Metrics and reports are the feedback mechanisms that allow project managers to determine if they are on schedule, and allow senior management to see if there are problems that need to be addressed. They are also the mechanism behind process improvement. Having well defined, measurable processes that are consistently implemented is a first step to providing valid metrics. By having the results of those processes recorded in the same repository as the development artifacts are managed in, it is easy to produce a relevant set of related metrics that span the various development phases of the lifecycle.
Ideally your ALM toolset should provide built-in analytical support, providing effective data mining of all the valuable activity and artifact data it is collecting. Such analytical support should encompass dashboards that provide high level overviews of relevant information, and the ability to drill down into the details where necessary. This is where having actively managed trace relationships that can be traversed in either direction can be a major help. Realtime generation of reports and dashboards is essential to allow timely management decisions.
Summary
Effective embedded systems engineering requires a set of well defined, measurable processes and practices to be implemented, which span all phases of the product development lifecycle. Many of these processes and practices can be very onerous if implemented manually. Embedded systems engineering teams should look to ALM tools to streamline and automate the implementation of these processes and practices as much as possible. Process enforcement and separation of roles and responsibilities are important requirements for such ALM tools. A centralised repository to record the results of all activities and capture all development artifacts allows for secure control over these corporate assets and enhances the chances of maintaining the trace relationships between the various artifacts.