Mirtalebi - Embedded systems architecture for agile development: a layers-based model

Mohsen Mirtalebi 2017

Mohsen Mirtalebi 1

(1)

What does developing a real-time system project have in common with a construction project , from the project management perspective? Can we develop and manage both projects with the same methodologies and tools? Some of you might think from a project management standpoint, developing real-time or embedded systems should not resemble developing a construction project. Although both might look similar organizationally and share the same types of resources such as time, money, and people; however, the fact that software has become an integral part of embedded systems will significantly differentiate these two projects from each other. Now, this important question arises: why is it that in many companies, both developments are called projects and use the same project management tools? The answer to this question will go beyond the boundaries of what the science of management can offer. This is because the sciences involved with developing real-time systems are very new and are in a constant state of change. Therefore the word project might carry a misleading connotation when its used for developing embedded systems. But this misconception has deeper roots than one might think. We all have seen many leaders in the embedded systems industry still utilize the same tools and methods that a construction company uses in developing their projects.

Nevertheless there are very valuable lessons in studying the construction projects , not in the management methods that have been used for years but in their own schools of thought. The construction industry has evolved through their thousands of years of history. All in all, the traditional management tools can work for real-time systems projects but in no way can one call this type of project management efficient for developing mid- to large-size embedded systems. Through reading this book you will realize how developing embedded systems are fundamentally different from any other types of projects. To start off, lets avoid the use of the term project temporarily as it might misleadingly imply only a process. An embedded system development is not just a process, it is a product integrated into a process. Although you might say a physical building is considered a product but it is not, because it lacks manufacturing of the same building in a volume of thousands of identical copies. Since a building is not a product, therefore, the term project shouldnt apply to embedded systems. If you want, you can, but keep in mind, our embedded system development project implies the process and product.

The fact that there will be thousands of copies of what you are making in the market makes the concept of efficiency of grave importance. An efficient development method results in an efficient product, and this translates directly to waste elimination, which creates direct economic impacts on both our company and customers through our process and products respectively. If we reduce the cost of development, our product would become cost effective and more competitive in pricing. In return it will bring a considerable amount of saving of costs to our customers. Combine efficiency and the astronomical numbers of embedded systems used currently across the globe, and we will come to the realization that the efficiency we intend to create will propagate to the furthest corner of the earth. Now this is a true green process. So forget not about the green products, but instead imagine your product will be the greenest of all. However, for some reasons, the idea of green in the industry has been slowly becoming a concept confined only to some promotional tools for marketing biodegradable materials in products or environmentally compliant methods such as ISO14000.

Although the recent waves of the green movement in the waste management and manufacturing process improvements are very good starting points for creating efficient systems, the bulk of waste in resources happens during development of products of any sorts. It is ironic that the term green, which would imply efficient should result in lower costs; but rather it imposes additional compliance regulations by which the manufacturers must assign budgets to maintain. This will result in higher developmental costs and longer product time to market, which consequently results in higher product prices defeating the purpose of being green. As we can see, a true green process results in better economic impacts such as a lower finished cost of the product without compromising the quality of the product. Therefore our concept of green runs a bit deeper, and it starts from where the first idea of a product sparks; however, it doesnt stop there and it continues to bear fruit while it runs its entire course of product life cycle. The Agile method of development is one way to reduce the waste since these methodologies were initially created to specifically target waste; however there are two shortcomings in these frameworks. One is that most Agile methods are optimized for software products, not embedded systems that are comprised of both software and hardware. Also, embedded systems are produced in order to carry out critical applications where general purpose computers are not to be trusted to perform the tasks; therefore saving costs is not the main objective of creating these systems.

In other words, most real-time systems are mainly designed to carry out control functions with critical applications. The Agile methods give waste elimination the highest priority, which could make us happy about the efficiency portion, but they fail to put enough emphasis on the robustness of the product. A good example of this is the Microsoft products that are developed through Agile methods . Their numerous after-release software patches and their daily software updates are evident that robustness is not high on their list. We are not to blame one product over its lack of quality. What we want to say is that, when there is not enough emphasis on one aspect of product or there is so much of it on another aspect, people who follow those methods blindly might not be able to put things in perspective. In addition, since in the span of development time and also product life cycle the technology and hardware components can change, it is very important to plan carefully ahead. While an Agile method empowers the project to deal with short-term changes, it might make it easier for its followers to abandon long-term plans for the product. The real consequence of this approach is that the importance of architecture in product development will be devalued. As you can see later, the product architecture plays a vital role in developing the embedded systems.

A project manager , in any type of project, from construction to hi-tech needs to put several hats on during the life of the project. In a real-time system development project, a manager needs to interface with different stakeholders and internal and external customers at different phases of a project and needs to follow various life cycles including project, product, and software life cycles. However, a project manager is hardly a product architect. This is because most project managers are trained and skillful in the art of management rather than designing a real-time system. This book is intended to find the common aspects of various life cycles and introduce an inclusive methodology that would cover them all under one umbrella with an emphasis on the necessary amount of documentation. We are hoping that by the end by reading this book, if not anything, at least your outlook will change toward real-time systems development.

Furthermore, this book is for the embedded system project architects who are aware of steps involving developing a real-time system and not just the project. The detail of how to become aware of the design steps is through systematic use of a tool called the requirement model . This new addition to what Agile methods seem to be lacking will empower the project architects to create a robust architecture that would very well address the criticality of a real-time system development while creating an efficient process and product. The advantage of following an Agile method will break the never-ending cycle of analysis-paralysis that most classical product development methods suffer from. Nevertheless, we all know that the classical methods are the foundation of the new methods; therefore, the ideas discussed here might be new but backward compatible and are absolutely true to the traditional methods, especially the CPD framework. Nevertheless, this book will not discuss the details of any design standards; software and hardware testing methods such as white box, black box, or any hardware development phase such as hardware alpha and beta prototyping; and manufacturing bottlenecks such as functional and end-of-the line testing, but it will show you how to utilize these methods and tools when you get to the different phases of development.