Challenges in Embedded System Development: Balancing Cost, Time, and Quality

Introduction

An embedded system can be defined as an engineering artefact which involves computation subject to physical constraints. Physical constraints emanate from two types of interactions of computational processes. These are reaction to a physical environment and execution on a physical platform (Gupta et al., 2010). As such, the main physical constraints are reaction and execution constraints. Embedded systems comprise of the hardware, software, and the environment. Embedded system developers operate in a very difficult commercial and technical environment. Projects are becoming increasingly complex and, thereby, hard to complete. On the other hand, competition in the market has intensified meaning that system developers have to constantly improve on their performance (Gerard et al., 2010). For instance, high-end mobile phones are currently being developed with sophisticated audio and video abilities and include PDA-style functionality. The traditional approach to embedded system development view cost, time, and quality as three vertices of a triangle. Normally, the traditional approach looks at optimizing any of the two vertices while focusing little on the third vertex. However, this approach has become increasingly untenable as system development needs to focus on all the three vertices (Broy et al., 2012). To achieve all the three vertices, there is need for disruptive changes in the way embedded systems are designed, developed, and tested. The need to achieve all the three vertices makes embedded system development to be challenging.

Challenges of embedded system development in practice

There are five main challenges that are experienced in practice when developing embedded systems. These are complexity, optimization, interdependency, verification, and tools.

Complexity

Complexity in embedded systems development arises due to the combination of functionalities on one system. This increases complex standards, especially in media and wireless application. In addition, networking capabilities are increasingly being included in embedded systems (Sikora et al., 2012). As such, a design for an embedded system becomes a system of systems, thereby, increasing the complexity. The increased complexity of the designs of the embedded systems makes it to develop them in practice (Larsen et al., 2010). Apart from making it hard to develop embedded systems, complexity also increases the cost of developing these systems. It also increases the delivery time and negatively affects the quality of the system.

Optimization

Optimization is basically a cycle of design and evaluation. Optimization in the development of embedded system is hard because of the time needed to build a prototype or functioning system model to assess. An embedded system has both the software and hardware components which interact in a complex way with each other. It is thereby hard to select the best combination of the components (Voelter, 2010). Currently, the only way of optimizing embedded is by guesswork or prototyping various solutions. The time and cost involved in building a functioning embedded system means that it is only one design that can be designed. As such, this severely limits the optimization possibilities (Pries and Quigley, 2010). In addition, selecting a wrong combination in an attempt to optimize can result in the delay or even failure of a project.

Interdependency

Different components of the design process for an embedded system have become increasingly interdependent. On the other hand, majority of design processes keep design domains independent and separate. This makes it hard for one take advantage of these interdependencies or deal with them. The best example of the interdependency challenge in an embedded system is hardware/software co-design challenge (Shen et al., 2012). While the two parts are interdependent, they have separate domains which makes it hard to take advantage of their interdependency to enhance their performance or deal with the challenges that the come from the interdependency. This problem is also experienced in the relationship between behavioural modelling and implementation (Eklund et al., 2014). The system design and the choice of algorithm applied in behavioural modelling are partly reliant on the selected hardware. Conversely, the choice of the hardware is significantly dependent on the behavioural model. However, with each having its own separate domains, it is hard to develop a mechanism for the implementation of behavioural model.

Since there is no clear way of dealing with interdependencies in embedded systems, it is hard to make decisions that cut across domain designs. On the other hand, the existence of separate and unrelated design domains results in many versions of a design which are not synchronized (Gupta et al., 2010). It is thereby common to find many separate models of computation in a design process. For example, it is possible to find a behavioural model, an implementation model, and a fixed-point model in a design process (Broy et al., 2012). In the worst case scenario, differences in models of computation are not discovered until the development process of an embedded system reaches the production stage. In such a case, it becomes hard to deal with these differences.

Verification

Verification is complex topic that focuses on a wide range of issues. However, at its simplest, verification enquires about whether an embedded system, as implemented, meets the specifications highlighted in the design, no matter how complex the design is (Broy et al., 2012). For instance, for a safety critical system, there may be need to demonstrate that the system does not, at any point, move through a dangerous state. The challenge with verification is the cost involved in terms of time and resources. Some researchers argue that verification consumes 50 to 70 percent of the project development time (Shen et al., 2012). With the complexity of embedded systems increasing by the day, the situation is likely to worsen unless the techniques used to carry out verification are changed. Even with the development of automated verification techniques, for complex embedded systems, it is hard to achieve automation. In addition, the current design processes for embedded systems make it hard to find mistakes early enough in the development process. As such, it is hard to correct the errors.

Tools

Tools are an important part of the development process in embedded system. The tools used in the development of embedded systems are much less sophisticated. In general, the current integrated development environments (IDEs) are effective at low level development. However, they do not provide more sophisticated development methods such as refactoring which can be used to handle the development of complex embedded systems (Gupta et al., 2010). In addition, these tools focus on only one stage of development or one design domain. There is also limited integration among the tools, making it hard to develop the embedded systems in practice. The point solution nature of the existing design tools makes it hard to achieve a coherent workflow and tool-chain integration (Broy et al., 2012). For instance, it makes it hard to achieve cross domain optimization. This challenge can be dealt with by improving the tools used in the development of embedded systems.

Assessment of the agile software development methods

There are two main agile software development methods. These are Scrum and test-driven development (TDD).

Scrum

Product backlog is basically the project that is supposed to be implemented. In this case, it is the embedded system that should be developed. The elements that define a product backlog under scrum include the size, complexity, and features of a system. Sprints, under scrum, are cycles which take a maximum of one month (Hamid et al., 2013). In each sprint, a part of the project is developed. Sprint planning, thereby, involves defining the goal that is supposed to be achieved in a certain sprint, the strategies that should be used to achieve this goal, and the items in the product backlog that should be focused on. Sprint execution involves the performance of all the work that needs to be done at a certain cycle. Daily scrum is an assessment of what has been accomplished and what the scrum team plans to do next. It also involves identification of the problems experienced and deciding on how to solve them (Broy et al., 2012). Sprint review is to assess the project, make adjustments, and adapt it to changes experienced among consumers. Lastly, sprint retrospective is an analysis of what is and is not working in the development of the system.

Strengths of scrum

One of the strengths of scrum is divides a project into manageable sprints. As pointed out, embedded systems have become increasingly complex in design. It is thereby hard to tackle them as a whole (Gupta et al., 2010). Dividing them into small parts reduces the complexity, making it easy to develop them. Another advantage of scrum as a software development method is at each sprint, the developed part of the system is tested and changes implemented to make it better (Shen et al., 2012). Scrum, thereby, makes it possible for mistakes to be dealt with at the early stages of development.

Being agile, scrum also adopts feedback from stakeholders and customers in the development process of a system. At each sprint, scrum requires the development team to take into account the ideas and opinions of stakeholders and customers (Eklund et al., 2014). This allows for the developed system to not only be of high quality and low on errors but also adequately meet the needs of customers in the market. Lastly, scrum allows for ease of coordination among development team members. With the members holding constant meetings during the implementation process, each member has a chance to offer their opinions and ideas on how best to develop the system (Kaisti et al., 2013). Members also get the opportunity to highlight how best the team can work. This does not only enhance the overall performance of the team but also improves the level of coordination among members, especially those handling different parts of the system.

Weaknesses

Despite its strengths, scrum has also a number of weaknesses. One of them is it results in delays as a result of lack of a definite end-date. Under scrum, project development is carried out in sprints which vary in time and can be adjusted due to new developments (Broy et al., 2012). With constant adjustments at each print, it is hard to determine the exact date at which a project will be complete. Another weakness of the scrum is there are high chances of failure in the development of a system if individuals are not committed or not cooperative (Shen et al., 2012). Scrum can only be successful if the team is working well. However, in situations where members of a team cannot agree on issues or are simply uncooperative, it becomes hard to successfully develop a system.

The reliance on a team under scrum may negatively affect the development process if one member leaves before the project is completed. As pointed out, the main principle of scrum is having a team working as one to achieve certain goals (Eklund et al., 2014). This implies that if one member of the team leaves, it may disorient the team, making it hard for it to perform well for the remaining part of the project.

TDD

Test-driven development (TDD) is a software development process which depends on repetition of a short development cycle. Under the TDD approach, the system developer first writes an initially failing automated test case which defines a new function or desired improvement (Kaisti et al., 2013). The developer then produces the minimum amount of code that can be used to pass the test. Lastly, the developer refactors the new codes to desired standards.

Strengths of TDD

One of the strengths of TDD is it allows developers to find errors early in the development stage. By developing test case, the system developer can easily identify the defects at the design stage and thereby correct them before it is late for any correction. Another advantage of TDD is flexibility and extensibility (Kaisti et al., 2013). TDD ensures that each unit of the whole system is tested using the automated test case. This makes it possible to identify areas that need to be adjusted or changed to enhance the performance of the system. Lastly, TDD has unparalleled test coverage and streamlined codebase (Hamid et al., 2013). TDD uses the test first and code later approach. As such, there is no possibility of failing to carry out a test before developing a code. This ensures that errors are dealt with before coding takes place. As such, there is limited risk of errors in the final system.

Weaknesses

One of the weaknesses of TDD is it takes a lot of time, making it hard to develop a system on time. For example, a lot of time is spent on testing and coding, thereby increasing the time needed to complete a project (Shen et al., 2012). Another weakness of TDD is for complex systems, it may not be easy to write test cases. This might hamper the development of a system. Lastly, it is hard to develop a test case for the interface due to continuous changes.

The best method to adopt for embedded system development

The best method to adopt for embedded system development is scrum. One of the reasons is because the method is ideal for complex systems due to its ability to break a system into manageable parts (Eklund et al., 2014). Another reason is it scrum brings people of different skills together. This helps to assemble a team of individuals with varying skills, making it easy to develop a system.

Recommendations

In adopting an agile software development for embedded system development, there are a number of things that the project owner should focus on. One of them is time they wish the project completed. For example, scrum is not for its time consumption. The project owner must ensure that they have factored in the issue of time in making decisions concerning the method to adopt. Another thing that should be considered is the cost (Eklund et al., 2014). Any project is usually carried out within a certain cost. The selected method must be in line with the intended budget. Lastly, the system being developed must be realistic and achievable (Kaisti et al., 2013). With increased competition in the market, some developers want to develop something unique for the market. However, their ideas may be unrealistic. It is important, thereby, to be realistic in designing systems.

Conclusion

Embedded system developers operate in a very difficult commercial and technical environment. Projects are becoming increasingly complex and, thereby, hard to complete. There are five main challenges that are experienced in practice when developing embedded systems. These are complexity, optimization, interdependency, verification, and tools. There are two main agile software development methods. These are Scrum and test-driven development (TDD). The best method to adopt for embedded system development is scrum. Scrum is ideal for complex systems due to its ability to break a system into manageable parts and scrum brings people of different skills together. This helps to assemble a team of individuals with varying skills, making it easy to develop a system. In developing an embedded system and choosing the agile software development method to use, there is need to consider factors such as cost and time.

References

• Broy, M., Kirstan, S., Krcmar, H. and Schätz, B., 2012. What is the benefit of a model-based design of embedded software systems in the car industry?. In Emerging Technologies for the Evolution and Maintenance of Software Models (pp. 343-369). IGI Global.
• Eklund, U., Olsson, H.H. and Strøm, N.J., 2014, May. Industrial challenges of scaling agile in mass-produced embedded systems. In International Conference on Agile Software Development (pp. 30-42). Springer, Cham.
• Gerard, S., Babau, J.P. and Champeau, J., 2010. Model driven engineering for distributed real-time embedded systems. Wiley-IEEE Press.
• Gupta, R., Bera, J.N. and Mitra, M., 2010. Development of an embedded system and MATLAB-based GUI for online acquisition and analysis of ECG signal. Measurement, 43(9), pp.1119-1126.
• Hamid, B., Geisel, J., Ziani, A., Bruel, J.M. and Perez, J., 2013, June. Model-driven engineering for trusted embedded systems based on security and dependability patterns. In International SDL Forum (pp. 72-90). Springer, Berlin, Heidelberg.
• Kaisti, M., Mujunen, T., Mäkilä, T., Rantala, V. and Lehtonen, T., 2014, May. Agile principles in the embedded system development. In International Conference on Agile Software Development (pp. 16-31). Springer, Cham.
• Kaisti, M., Rantala, V., Mujunen, T., Hyrynsalmi, S., Könnölä, K., Mäkilä, T. and Lehtonen, T., 2013. Agile methods for embedded systems development-a literature review and a mapping study. EURASIP Journal on Embedded Systems, 2013(1), p.15.
• Könnölä, K., Suomi, S., Mäkilä, T., Jokela, T., Rantala, V. and Lehtonen, T., 2016. Agile methods in embedded system development: Multiple-case study of three industrial cases. Journal of Systems and Software, 118, pp.134-150.
• Larsen, P.G., Wolff, S., Battle, N., Fitzgerald, J. and Pierce, K., 2010. Development process of distributed embedded systems using vdm. Overture–Open-source Tools for Formal Modelling TR-2010-02.
• Pries, K.H. and Quigley, J.M., 2010. Scrum project management. CRC press.
• Shen, M., Yang, W., Rong, G. and Shao, D., 2012, June. Applying agile methods to embedded software development: A systematic review. In Proceedings of the Second International Workshop on Software Engineering for Embedded Systems (pp. 30-36). IEEE Press.
• Sikora, E., Tenbergen, B. and Pohl, K., 2012. Industry needs and research directions in requirements engineering for embedded systems. Requirements Engineering, 17(1), pp.57-78.
• Voelter, M., 2010. Embedded software development with projectional language workbenches. In International Conference on Model Driven Engineering Languages and Systems (pp. 32-46). Springer, Berlin, Heidelberg.