Food & Beverages

A Platform-Based Software Design Methodology for Embedded Control Systems: An Agile Toolkit

A Platform-Based Software Design Methodology for Embedded Control Systems: An Agile Toolkit Lucas Cordeiro 1,2, Carlos Mar 1, Eduardo Valentin 1,4, Fabiano Cruz 1,4 Daniel Patrick 1, Raimundo Barreto 1,
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
A Platform-Based Software Design Methodology for Embedded Control Systems: An Agile Toolkit Lucas Cordeiro 1,2, Carlos Mar 1, Eduardo Valentin 1,4, Fabiano Cruz 1,4 Daniel Patrick 1, Raimundo Barreto 1, and Vicente Lucena 3 1 Departamento de Ciência da Computação - Universidade Federal do Amazonas (UFAM), Brazil {caam, dpp, 2 Centro de Ciências, Tecnologia e Inovação do Pólo Industrial de Manaus (CTPIM), Brazil 3 Centro de P&D em Tecnologia Eletrônica e da Informação (CETELI/UFAM), Brazil 4 Instituto Nokia de Tecnologia (INdT), Brazil {eduardo.valentin, f Abstract A discrete control system, with stringent hardware constraints, is effectively an embedded real-time system and hence requires a rigorous methodology to develop the software involved. The development methodology proposed in this paper adapts agile principles and patterns to support the building of embedded control systems, focusing on the issues relating to a system s constraints and safety. Strong unit testing, to ensure correctness, including the satisfaction of timing constraints, is the foundation of the proposed methodology. A platform-based design approach is used to balance costs and time-to-market in relation to performance and functionality constraints. It is concluded that the proposed methodology significantly reduces design time and costs, as well as leading to better software modularity and reliability. 1 Introduction Embedded computer systems are used in a wide range of systems from machine condition monitoring to airbag control systems. As the system complexity increases, its development lifecycle is also affected. Because of that, system development methodologies must be applied in order to manage the team size, the product requirement (scope),and to meet the project s constraints (time-to-market and costs). Furthermore, embedded software (ESW) plays an important role in this kind of system mainly due to its flexibility and consequently to overcome the time-to-market pressure. Nevertheless, many development methodologies that are used to produce software that runs on the personal computers (PCs) are not appropriate for developing discrete control systems. These devices share common characteristics with typical embedded real-time systems, i.e. they have a data acquisition stage, the application of a complex control algorithm, followed by output of a result. The correctness of these systems depend not only on the results, but also on the time in which these results are produced [11]. Therefore, this kind of system contains very different characteristics such as dedicated hardware and software, and constraints that are not common to PCs based systems (e.g., energy consumption, execution time, memory footprint). In addition, severe coding errors such as implementation of finite-state machine (FSM), stack/memory overflow, and timing must be avoided when designing the ESW. Another important point is that some embedded control systems may put lives at risk (mission criticality) if some failure occurs. Therefore, definitively, these systems should be treated differently from the case where the only cost of failure is the project s investment. Based on this context, we propose a platform-based software design methodology based on the agile principles such as adaptive planning, flexibility, iterative and incremental approach in order to make the development of embedded control software easier. To achieve that, this methodology is composed by practices from Software Engineering and Agile methods (Scrum and XP) which aim at minimizing the main problems present on the software development context (i.e. requirement volatility and risk management), and by others practices that are needed to achieve hardware and software development (i.e. platform-based design [23]). With this goal in mind, we also focus our attention on hardware-bound embedded software that imposes several challenges to the software design methodology (e.g., real-time and code size). The remainder of this paper is organized as follows: Section 2 summarizes the related works. Section 3 is concerned with describing the proposed agile development methodology and its main components (processes, lifecycle, roles and responsibilities). Section 4 shows the application of the proposed methodology by focusing on the processes that were applied to the digital soft-starter and induction motor simulator prototypes. Section 5 shows the experimental results of our proposed methodology. Finally, section 6 summarizes this paper and identifies the next steps of this research. 2 Related Works There are several works about agile development methodologies for embedded systems. However, there is an interesting paper that describes the experience of applying Agile approaches to the development of firmware for the Intel Itanium processor family [8]. In this paper, they identified the agile practices that the Intel team successfully applied, but they did not take into account the hardware related development. Moreover, this work did not mention how to address the non-functional requirements (e.g., code size and real-time) and did not provide any experimental results of their work. Manhart and Schneider [13] also related a successful industrial experience when partially adopting agile methods in the production of software for embedded systems. Indeed, they made slight modifications in a well established software development process for the automotive branch adopting some agile elements in order to adequate their process to new needs as flexibility and high speed software production. As pointed out in the paper many other application areas may benefit from their experiments, nevertheless the authors did not present any measurement results that could prove their expectations. A very interesting paper that describes the experience of applying agile test techniques to ESW is presented in [17]. In this paper, the authors focus on the test techniques that were applied to a mobile spectrometer, using a newly developed proprietary technology. In another paper, Koss and Langr propose some adaptations of test techniques used in object oriented (OO) programming languages to ESW written in C language [12]. There is also an interesting work that describes the application of Extreme Programming s test driven development to embedded systems featuring custom hardware and software designs [6]. In this paper, an agile method for testing embedded systems using existing software test frameworks and methodology is presented. The conceptual framework proposed by Ronkainen e Abrahamsson, evaluate the possibility to use agile development practices in embedded software environment [16]. Therefore, they define requirements for new agile methods which include (i) special emphasis on hardware/software architecture, (ii) refactoring must be integrated into the configuration management system, (iii) techniques to measure the code mature in different development phase, and (iv) techniques to design test cases that take into account not only the correctness but also the timeliness of the application. Although this paper is totally conceptual, the requirements for new agile methods served as basis for our proposed methodology. Vicentelli and Martin propose a rigorous methodology that aims to (i) deal with integration problems among intellectual property (IP) creators, semiconductor vendors, and design house, (ii) consider metrics to measure embedded system design, (iii) work from conception to software implementation, and (iv) favor reuse by identifying requirements for real plug-and-play operation [23]. Nevertheless, they did not provide any concrete guidance and they rely on abstract rules of thumb only. Although the methodology proposed by them is totally conceptual, it also served as basis for the development of our proposed methodology. The hardware/software co-design methodology proposed by Gajski [7] aims to develop embedded systems by formally describing the system s functionalities in an executable language rather than a natural language. The executable specification is refined through the system-design tasks of allocation, partition, and refinement. Estimators are also used in order to explore design alternatives. However, this methodology does not provide any project management activity and assumes that most of the requirements are captured before applying the partitioning algorithms. From the point of view of embedded software design methodologies, the proposed work aims to: (i) tradeoff flexibility and performance by adopting highly programmable platforms, (ii) adopt processes and practices to develop ESW that is under stringent hardware constraints, (iii) support a software driven hardware development approach through a comprehensive flow from specification to implementation, (iv) propose test techniques in a combination we have not seen before, (v) make use of the iterative and incremental approach in order to offer clearly an iterative process where the designer can validate the system specification, and (vi) provide experimental results of the application of the proposed methodology in the embedded control systems domain. The next section describes the proposed methodology and its main components (processes, lifecycle, and roles). 3 Proposed Development Methodology The proposed methodology aims to define roles and responsibilities and provide processes, lifecycle, practices and tools to be applied in embedded real-time system projects. It contains three different processes groups that should be used during the system development: system platform, product development and management. The system platform processes group aims to instantiate the platform for a given product. It means that the system designer must choose the system components that will be part of the architecture and API platforms from a platform library. After that, the system designer has still the possibility to customize the architecture and API platforms in order to meet the application constraints. The customization process is carried out by programming the designerconfigurable processors and runtime-reconfigurable logic integrated into the platform. The customization process is carried out by successive refinements in an iterative and incremental way into the proposed methodology. The product development processes group offers practices to develop the application s components and integrate them into the platform. The functionalities which make up the product are partitioned into either hardware or software elements of the platform. Our partitioning algorithms used to carry out this task take into account the energy consumption, execution time, and memory size of the application s components. In addition, the partitioning technique is also applied in an iterative and incremental way. The mechanical design is also part of this processes group, but it is out of the scope of this paper. In addition to that, this processes group aims to apply a novel test design approach in order to improve the system s coverage by stressing and covering variables and function calls in ESW. As depicted in Figure 1, this approach focuses on designing firstly the unit and functional tests before really implementing the application s code. The application s code is implemented by making use of the API platform which provides a unique abstract representation of the architecture platform through the software layer. From the application s code, the formal translator converts it to a formal model with the purpose of allowing an embedded software engineer to verify that certain safety properties hold in the model (by using temporal logic formulas and model checking). Furthermore, if the model does not satisfy the specification then a counter-example is generated which is included into the test suite and after that it is used to adjust the application s code. Analysis of performance and energy consumption are carried out using the instruction set architecture (ISA) of the platform. This analysis is mainly based on the unit and functional tests to sim- Figure 1. Test Design Approach. ulate the system s behavior and ensure that constraints are satisfied during the development cycle. The product scope, time, quality, and costs parameters are monitored and controlled by the product management processes group. These parameters also influence the system platform and product development processes groups. When the project starts with an infeasible project plan which needs corrective actions to be carried out then this processes group aims to get the project back on the track and ensure that the project s parameters are met. The product management processes group consists of the practices promoted by the Scrum agile method as well as the agile patterns described in [3, 18]. It is important to point out that the processes of the methodology were proposed in order to cover the system development lifecycle as described by [1]. Therefore, the main motivations of the proposed methodology include, but are not strictly limited to provide: (i) a full lifecycle coverage, (ii) project management activities, (iii) flexibility, (iv) means to address the non-functional requirements, (v) a software driven hardware development approach, (vi) concrete guidance of the processes, and (vii) experimental results. The next subsections are concerned with describing the processes groups, roles and responsibilities, and the processes lifecycle of the proposed methodology. 3.1 System Platform Processes Group The system platform processes group is composed of the following processes: product requirements, system platform, product line, and system optimization. Figure 2 depicts the processes that are related to system platform processes group. The product requirements process aims to obtain the system s requirements (functional and nonfunctional) that are relevant to determine the system platform in which the product will be built. The platform instance process helps the development team define the system platform by making use of a set of design tools and benchmarks. Figure 3. Product Development Processes Group. Figure 2. System Platform Processes Group. After defining the system platform, the product line process helps the development team setup the repository in which the system platform components will be available to the product development. This process also allows the development team to implement and integrate system s functionalities into the system and release new product versions into the market. After implementing and integrating the system s functionalities into the product development line, the system optimization process providesactivitiesto ensure that system s variables such as execution time, energy consumption, program size and data memory size satisfy the application constraints. 3.2 Product Development Processes Group The product development processes group is composed of the following processes: functionality implementation, task integration, system refactoring, and system optimization. Figure 3 depicts the processes that are related to product development processes group. The functionality implementation process ensures that test cases are created for every product s functionality. This process helps increase the product quality and reduce the creation of complex functions. Moreover, it also helps create a comprehensive test suite for testing and validating that the API Platform layer will function properly for the software applications by making use of verification techniques (e.g., model checking). The task integration process provides means to integrate new implemented functionalities into the development line of the product without forcing the other team members to work around it. The system refactoring process helps the development team identifies opportunity to improve the code and changing it without altering its external behavior. After refactoring the code, the system optimization process allows the development team to optimize small part of the code by making use of profiler tools that monitor the program and tells where, for instance, it is consuming time, energy, and memory space [15]. This process guarantees that software metrics meets the system constraints. 3.3 Product Management Processes Group The product management processes group is composed of the following processes: product requirements, project management, bug tracking, sprint requirements, product line, and implementation priority. Figure 4 depicts the processes that are related to product management processes group. The product requirements process (that also belongs to the system platform processes group) aims to obtain the system s requirements (functional and non-functional) that must be part of the product. The project management process allows the development team to implement the system s requirements by managing the product and sprint backlog, coordinating activities, generating system s build, and tracking the product s bug. Figure 4. Product Management Processes Group. The bug tracking process allows the product leader to manage the lifecycle of the project s issues (bug, task, and enhancement) and provide the needed information about the product quality through the release notes for the end user. The sprint requirements process allows the development team to analyze, evaluate, and estimate the system s functionalities before starting a new project s sprint. This information is included into the sprint backlog which will help the development team partition the system functionalities into either hardware or software before starting the sprint. The product line process guarantees that the system functionalities implemented during the sprint will be integrated into the product development line. This process also helps the development team to release new product versions into the market. The implementation priority process helps the product leader manage any kind of interruptions that may impact the project s goals. This process guarantees that the project s tasks are 100 percent completed after initiated. 3.4 Roles and Responsibilities The proposed methodology involves four different roles and the responsibility of each role is described as follows: Platform Owner: Platform owner is the person who is officially responsible for the products that derive from a given platform. This person is responsible for defining quality, schedule and costs targets of the product. He/she must also create and prioritize the product backlog, choose the goals for the sprints, and review the product with the stakeholders. Product Leader: Product leader is responsible for the implementation, integration and test of the product ensuring that quality, schedule, and cost targets defined by the platform owner are met. He/she is also responsible for mediating between management and development team as well as listening to progress and removes block points. Feature Leader: Feature leader is responsible for managing, controlling and coordinating subsystem projects, pre-integration projects, external suppliers that contribute to a defined set of features. The feature leader also tracks the progress and status of the feature development (deliverables, integration and test status, defects, and change requests) and reports the status to the product leader. Development Team: The development team which may consist of programmers, architects, and testers are responsible for working on the product development. They have the authority to make any decisions, do whatever is necessary to do (according to the project s guidelines), and ask for any block points to be removed. If the product to be developed is small, i.e. it is composed of few components (less than 50 KLOC) and does not require other development teams to implement the product s functionalities then one product leader and the development team are enough for the product development. On th
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!