Embedded Software Engineering
Term Paper
By: Teri Williams
CSC532 Fall 2008
Louisiana Tech University
In today’s society, people rely heavily on technology. Whether using a cell phone to make a call while away from home or driving a car to work, the dependence on complex systems is prevalent. In addition, the abilities of these gadgets have advanced exponentially in the past few years, and people have become dependent on ‘get it now’ features. Now everyday items are expected to perform a multitude of tasks simultaneously with minimal effort from the user. In order to execute these functions, these products use software contained in the system packaging. This computer software, known as embedded software, is written for equipment whose primary function is not computing; such as cars, cell phones, airplanes, robots, and medical devices. The market for items with embedded software is growing at an accelerated rate and it is imperative that designers and developers understand the challenges of the embedded software development environment in order to meet the high quality standards on time as end users have come to expect.
The increased demand for embedded software engineers is prevalent globally. The growth in the embedded software market is steadily increasing, largely due to advances in consumer electronics, and continued increases in spending for the military and aerospace industry, industrial automation, and telecommunication industries (Figure 1). An independent marketing company, Venture Development Corporation, estimated that in 2004 the market for embedded software reached $905 million, which was an increase of 20.9% over the previous year. They also estimated the Average Annual Growth Rate (AAGR) of this market would be 16% from 2004 to 2009. (1)
Figure 1: Global Embedded Software Revenue by Application, Source: BBC (4)
According to the 2007 Japanese software industry survey report, issued from the Ministry of Economy, Trade and Industry in Japan, 40% of the revenue in software developments stems from embedded software. The number of embedded software engineers in 2006 was estimated to be 235,000, which falls short of the required personnel by an estimated 99,000. (2) In China, 30% of software revenue is realized through embedded software. Embedded software products provide 35.3% of the total revenue for the top 100 software companies, while six of the top ten software companies are dedicated to embedded software. (3)
The British Broadcasting Corporation’s (BBC) research into embedded software found that in 2004, the United States owned the majority of revenue at 48%, with Europe, Japan and Asia comprising the remaining percentages (Figure 2). The annual growth rate in this market was estimated to be 15% for all parties, except for China which was estimated at 25%. (4) This overall growth trend supports the need to develop qualified embedded software engineers (ESE).
Figure 2: Global Embedded Software Revenue by Region, Source BBC (4)
Embedded software has specific needs that differ from the normal software development and poses quite a number of challenges for the software engineer. In non-embedded software development, the application is developed for computational machinery, with a known operating system and known hardware that stays constant during multiple iterations of development. The focus for this engineer is the application, not the environment. However, the ESE is not so lucky. While the general concept and design of the hardware and packaging is known, it is not concrete and most likely will change during development. Added to this, the ESE is responsible for designing and integrating the operating system into the hardware. Another issue the ESE must face is that most designs are proprietary and different from design to design and very specific to the product. To make everything more complex, there are timing constraints, limited memory and power use, and many times concurrent software implementations. (5)
It is important to understand the motivation behind embedded software development. Unlike traditional software, embedded software is not for resell. It is designed for a specific purpose designated to a product slated for market. The software is only a part of the whole concept, and is a sub-process of systems engineering. Many times, the embedded systems are often systems of systems and are acting together in larger systems such as the anti-lock braking system in a car. As technologies are becoming more advanced and interactions among components are more intricate, current development procedures are becoming ineffective. As of 2003, existing development technologies did not address specific impacts or allow for customization in the embedded domain. The software constraints due to hardware and packaging were usually not considered. These development technologies did not address specific application to the product domain, such as automotive systems, telecommunications, or consumer electronics. (6) It is very challenging for ESE’s to coordinate their sub-process with the mechanical and electrical engineering sub-process. However, the increased complexity of embedded products do not allow for insular development. The embedded domain needs specially designed development technologies.
Project MOOSE (2003), a study aimed at improving embedded software development, was performed by Software Engineering Methodologies for Embedded Systems as a part of Information Technology for European Advancement (ITEA). The first report from this project explained why many companies were not using current development software. The first problem was compliance with legacy systems. In order to ensure compliance, older components were used with little additional design or adaptation, which creates a bottom-up approach to design and most software development tools use a top-down approach. The second problem was that the design process for interacting components between requirements and other artifacts was not clear and easy to use. Also, integrating the tools with current solutions was difficult to accomplish. The third problem was that the complex environment of the embedded design required experienced and skilled software engineers, but the development process included shareholders that did not understand the meaning of formal development languages. Lastly, the embedded software’s nonfunctional properties were not explicitly stated in the requirements specification, which can be detrimental if the requirements do not take into consideration for real-time requirements or power consumption and memory use. (6) Since this project, the focus on finding a suitable development process for embedded engineering increased and more solutions were found. However, there were still problems.
In recent years, the increased dependence on embedded software to provide a multitude of functions on a common execution platform, many times with commercial off the shelf (COTS) hardware has resulted in a variety of system difficulties. Many of these difficulties are related to mismatched assumptions between system engineers and software engineers. Many systems faults and failures are not captured by traditional fault tolerance techniques, which are attributed to a lack of understanding the impacts of transferring tested software to different runtime architectures and the complexity of integrating many components into the physical environment and packaging. One of the causes of this problem can be traced back to improper and incomplete documentation. Another source is due to having different parts integrating together and sharing resources which many times results in mismatched assumptions in both the functional and non-functional requirements. The lack of proper system analysis during the design phase is evident as these problems usually are discovered during integration and testing. (7)
Many of these problems are significant and lead to increased development, which in the big picture decreases profit margins. The following examples help illustrate the magnitude of this issue:
- Mismatched Assumptions: The Ariane 5 is a launch system, manufactured by the European Space Agency, used to deliver payloads into space. During the testing phase, the rocket exploded 37 seconds after launch on the first flight. Upon investigation, it was discovered that a malfunction in the computer software caused the problem. This “most expensive computer bug in history” was due to mismatched assumptions about computing precision and measurement units when the software system was moved from Ariane 4 to Ariane 5. A data conversion from a 64-bit floating point number to a 16-bit integer caused a rounding error when the domain value exceeded the 16-bit capacity. (8)
- Resource Sharing Errors: Daimler-Benz automotive industries experienced difficulties with one of their auto model configurations. A shared bus between the navigation system and proximity warning system occasionally caused a delayed response from the warning system. (7)
- Scheduling Issues: The Mars Pathfinder is a spacecraft whose mission was to take observations concerning the Martian environment. Overall, the mission was successful. However, the information initially sent from the Pathfinder reported unexplainable system crashes. Upon many hours of analysis, the error was attributed to priority inversion. The Pathfinder had an information bus, which was a shared memory area used for passing information to different spacecraft components. Access to use the bus was handled with mutual exclusion locks. To manage the system, a bus management task was performed regularly, with a high priority. A communications task was assigned a medium priority. Experimental data was passed and published less frequently and so was assigned a lower priority. The problem occurred when a lower priority task was in progress and a higher priority task came due to run at the same time the medium task was due to run. The mutual exclusion locks had issues at this point, causing the medium priority task to interrupt the low priority task and the low priority task did not complete the release of the lock to the high priority task. Since the high priority task was deemed time critical and did not run, after a certain amount of time, the system would determine that an unrecoverable error occurred and reboot the system. (9)
- Migration Issues: When migrating applications to different runtime architectures and hardware, it was observed that the F16 fighter jet experienced an unexpected latency leading to instability. This latency displayed blurred targets on the cockpit display. (7)
What actions should the embedded software industry take to mitigate these issues? Based on the research articles presented in this paper, the consensus is that software engineers must be involved in the initial stages of the product development along with the system engineers and they must be consulted and kept in constant communication throughout the product life cycle. In addition, a unified and consistent language is essential to prevent miscommunication and false assumptions. The way ahead is to standardize development vocabularies and to embrace model base engineering (MBE) practices.
The International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) recognizes the need for a standardized vocabulary and is progressing in standardizing terminology and processes between the system and software engineering communities. (7)
MBE allows for earlier predictability in the development lifecycle, which can help alleviate mismatched assumptions, resource sharing problems, scheduling and migration issues. Traditionally, the system integration was focused on system engineering with emphasis on the hardware and its operational environment. With MBE, the focus is on embedded software which is then integrated with its environment, which highlights the shared computing platform use, multiple components and multiple tasks. Now, the total system is broken down into software components, which is logically integrated into the system via real-time tasks. The runtime architecture is deployed on a common platform within the system packaging. This process allows the system engineers and software engineers more interaction and communication throughout the lifecycle. (7)
The engineering models are more than just pictures, they express to all parties involved, including the stakeholders, the overall process. These models can help reduce development costs. By analyzing these models and their interaction, risks can be identified earlier in the development process and action can be taken to reduce the risks, lowering the overall product cost. Many model checking techniques have been shown to easily discover subtle error in the complex environment that was previously difficult to find during traditional testing approaches. (6) System fidelity is increased by using quantitative analysis during integration testing. Constantly updating the models as development progresses within a single modeling package ensures workability, eliminating additional validation steps, which reduces development time and costs. Having integrated models provide more flexibility, ensures intercommunication, and reduces maintenance and evolution costs by having standardized historical data. Finally, by using MBE, there is minimal overdesign as each team is not recreating the design, but working with existing design and integrating it within their part. (7)
The embedded software industry recognizes that MBE development technology has matured enough to be of benefit. These benefits include: a common modeling notation, model reuse, improved communications between developers and subcontractors through model integration ability, analyzable models and analysis results, a main source model for system architecture, improved system validation. (7) In addition, the investment in MBE training pays off immensely due to interoperability and time savings. As these MBE technologies are utilized in industry, user experience increases as well as the comfort of use. Not only are the benefits of MBE realized, the development of product standards and historical references are created.
As today’s technology advances, the burden of the embedded software engineer will not abate. Products will have more features, more integration, and much more complexity. To mitigate the multitude of development errors experienced in the past and to ease the workload of the engineer, industry language standards and MBE should be universally adopted and utilized. The more prevalent MBE becomes in society, the better embedded software engineers can meet the needs of the industry.
Works Cited
1.
2. Ministry of Economy, Trade and Industry, Committee of Promoting Embedded Software. Software Industry Survey Report. Japan : s.n., 2007.
3. Yimei, Kang. A Graduate Program on Embedded Software Engineering in China. s.l. : 20th Conference on Software Engineering Education & Training, IEEE, 2007.
4. BBC Research, The Hipeac Roadmap on Embedded Systems. European Network of Excellence on High-Performance Embedded Architecture and Compilation. Chapter 3. Market.
5. Day, Robert. The Challenges of an Embedded Software Engineer. s.l. : Embedded Technology Journal, 2005.
6. Graaf, Bas. Embedded Software Engineering: The State of the Practice. s.l. : IEEE Computer Society, 2003.
7. Feller, Peter H. ASSIP Study of Real-Time Safety-Critical Embedded Software-Intensive System Engineering Practices. s.l. : Carnegie Mellon University, February 2008. CMU/SCI-2008-SR-001.
Embedded Software Engineering – by: Teri WilliamsPage 1