São José dos Campos/SP - 23 e 24 de agosto de 2016 An Embedded Software Reuse Technique Based on Internal Services Components Applied for Nanosats JUNQUEIRA, D.V. 1, DOS SANTOS, W.A. 2 1 Instituto Nacional de Pesquisas Espaciais, São José dos Campos, SP, Brasil Aluno de Mestrado do Curso de Engenharia e Gerenciamento de Sistemas Espaciais CSE. 2 DEA-ETE - Divisão de Eletrônica Aerospacial - Supervisão de Bordo - Instituto Nacional de Pesquisas Espaciais, São José dos Campos, SP, Brasil de_junqueira@yahoo.com.br Abstract. Due to the growth of non-recurring engineering costs, that is, those generated by repeated solutions to each project, many organizations seek more disciplined design styles for dealing with them. Recurrence increases production costs and pressure to reduce the delivery time. Approximately 60% to 90% of an embedded system is quite similar to previously developed systems and can be reused. The same is observed in embedded systems components for space applications where 95% of them are reused and 90% consists of software. This work basically explores reuse with: (1) A layered-based software development for nanosat projects (2) A technique to develop to reuse embedded software components deployed on each layer (3) Assurance that projects tend to finish successfully and obtain higher productivity gains (4) Promotion of parallel development, and (5) A combination of software quality concepts required for components´ certification. 1. Introduction In embedded systems there are many variables in the software production process ranging from choosing the optimal microcontroller to carry out the project, through the aggregate peripherals and their drivers, up to the need for abstraction of hardware translated into the API and development of the application itself. This suggests a development process in accordance to software engineering phases, activities, artifacts and well-defined roles in order to controlled and monitored management. The software productivity is quite dependent to the chosen process and the type of software to be developed. One of the great challenges on companies is to look for ways to increase software productivity since studies show this as the major cause of project delays. One of the most effective ways is to introduce automation activities in this process, especially in embedded systems where this type of tool is sparse, since the software production process is still largely manual. Therefore, the aim of this article is to present a technique to build reusable software components that may be applied to a CASE tool allowing you to add lines of code responsible for performing the layers of drivers and API in an embedded software São José dos Campos/SP - 23 e 24 de agosto de 2016 project. Additionally, it will be shown an application of this technique on nanosats projects as an example. 2. Contextualization Some computer systems works with a software function library divided into layers, where the drivers´ layer are the closest functions to the hardware platform and the intermediate layer are functions that deviate from the drivers. The main purpose of this is supporting the project mission to a given portfolio or company segment where these functions precede the application. An example of such functions is those used in communication interfaces like the layers of TCP / IP stack. The use of these functions is independent of the project architecture either centralized as in integrated modular avionics (IMA) or distributed as federated systems, with or without use of an operating system (OS). The use of an OS will add intermediary functions in the project however these functions are related to diverse managements that an OS does on the hardware and not will add intermediate functions about the project's mission. The OS requires drivers for peripherals control and once the project apply hardware components which their interfaces are controlled by OS drivers, then the library drivers was already set. In this case the designs are dependent on these drivers and the OS as a whole, but it must analyze the viability of the remaining designs portfolio, if they may apply the same components, but without making OS use, or if the same component may be used by other OS. It is worth remembering that drivers belong usually to the manufacturer of these interfaces and, due to commercial, reasons provides drivers for an OS set which is applied on a large scale in a market segment. Mainly in low-cost projects one must make a careful analysis before adopting an OS, because either the cost of the project may rise or the selection of interfaces is restricted to particular OS driver suppliers. All these considerations are important for on-board space applications. The library of reusable software functions is useful for any project architecture whether it’s an integrated architecture where an OS is required with an API that enables to create and manage multiple partitions to applications or a federated architecture, where an OS may be not required. A space on-board library can help with both layers: the driver layer to the case of OS absence or if some drivers are not included in an OS image, as well as the intermediate layer through functions that help the applications and OS abstraction functions to allow the component to be controlled in more than one OS. 2.1. Software reuse through CCSDS-SOIS As the focus of Spacecraft Onboard Interface Services (SOIS) area of the Consultative Committee for Space Data Systems (CCSDS) include the standardization of generic satellite functions, one can notice services like Time Access Service (TAS) could be implemented in an Master Timer within a federated architecture for instance, in this case we would have a controller and a high-precision timer peripheral into Master Timer to send time data to synchronize a local clock of an C&DH for example. SOIS is a powerful library definition, because it includes generic functions for a satellite so a high rate of reuse is expected. In Nanosats of specific missions may not São José dos Campos/SP - 23 e 24 de agosto de 2016 meet such functions but even so will have their intermediate layers functions. An example is the camera which goal can be take pictures periodically, or scheduled or attending an asynchronous event.The functions as takePictures[n, x] where “n” is the number of pictures and it should respect a time interval “x” may be useful, as well as startRecording[], stopRecording[] and etc. These functions can make up the library of Camera ORU (Orbital Replacement Unit) along with SOIS services. Each SOIS service can be shared with other satellites according to network interface and standardization of the hardware controllers and peripherals. Since it is generic functions there is high probability of these services will be present in all satellite. So the SOIS services open up the possibility of reuse for a wide range of equipment. 3. Internal Services Components Abstracting from microcontroller its main peripherals and already introducing it on driver’s layer, we have: GPIO, UART, Timer, PWM and etc. As shown in Figure 1. Figure 1 - Driver's Layer Each of these peripherals must be setup and initialized as well as its application in other layers above this. We will call these hardware peripherals, when it aggregates functional characteristics of an Internal Software Component (IswC). The Internal Service Components (ISC) describes the intermediate layer of software functions that support the application and always make use of the IswC. At the camera, for example, its functions would frequently be the same as: takePictures[n,x], startRecording[], stopRecording[], etc. Once setup and initialized, the camera controller always will runs through of application call and, on this case, the camera has three ISC. 4. Library Overview Reuse is a consistent practice to develop software from a set of 'building blocks', such that the similarities with the requirements and/or architectural model with applications can be exploited to reach substantial benefits in productivity, quality and system performance. The ISC and IswC components compose the library which will be called by the project’s applications, such that the ISC provides the intermediate layer functions and the IswC provides the driver layer functions. We observe at Figure 2 an example of four projects P1,...,P4, and assuming that all of these projects can share the C1 hardware platform, if we are developing an C&DH, the controller is C1, and each cubesat project like P2, P3 and P4 will reuse the IswC and ICS from the library because the functions layers for C1 have been written in P1 and they can be reused in P2, ..., P4. The reutilization of IswC in other projects may reach 100%, since the C&DH of P1 was applied in all microcontrollers’ peripherals. The reuse of ISC can be highest, but it will depend on right planning, it involves useful São José dos Campos/SP - 23 e 24 de agosto de 2016 functions for the mission of P1 and also of common use for any mission. We will see on next topic other example of how to plan. We can reuse network peripherals, timer, ADC, GPIO and etc., with their proper functions, in addition to SOIS services. We reuse within the same project either because C1 may be used in other equipment different of C&DH as shows Figure 2. There is an augmented probability in IMA projects or in other projects in the same C&DH for instance. Figure 2 – Library Overview 4.1.An Example of Library use For the demonstration of reuse, it will be applied as example the TIMER peripheral, because it’s a common peripheral in microcontrollers. The Timer is a peripheral that implements features related to the control of time and in the C&DH, for example: Commands received from the Earth can be synchronized on orbit according to the clock; Commands to the Earth or to other equipment may be scheduled. Another function of Timer in C&DH is to keep a tracked time. This is usually used for the watchdog timer. Other equipment, such as those in the AOCS, applies timers to do periodic readings of their sensors and act on actuators within certain duration, then, it’s a common peripheral and widely used in various satellite subsystems. We have to think for TIMER in its main functions that may help the mission. This case will use the TIMER to count seconds as a clock, a counter that counts external events, we can use a GPIO port to introduce these events, and a comparator based on the internal clock that should compare with some defined value. These functions, for sure is base to meet some capacities of C&DH equipment like shown previously. The TIMER peripheral of microcontroller will require to three ISC in this approached solution:  ISC 1: Clock; São José dos Campos/SP - 23 e 24 de agosto de 2016  ISC 2: Counter;  ISC 3: Comparator. With our approach, it would be allowed to develop a software that generate autocodes of two layers as shown in Figure 3 in order to add programing code. ISC 1 ISC 2 ISC 3 Clock Counter Comparator TIMER IswC Figure 3 – TIMER layers The driver is represented by functions which will be necessary to setup and initialize the TIMER peripheral of the microcontroller in order to work as Clock, Counter and Comparator which are some generic and possible ways of operating a TIMER. Often this includes perform settings of its registers. The Intermediary layer uses the interfaces and settings made at Driver to provide ISC functionalities, and often is applied one TIMER for each function. 4.2. Library Architecture and Design The concept just mentioned will be applied to two families of microcontrollers as examples of use on 3 space projects which have implemented the same functionality, the C&DH. Consider a P1 nanosat and a P2 picosat project that share the same platform, the AT90S8535, an 8-bit, low power microcontroller based on AVR RISC architecture. Finally, consider the P3 project is the Trailblazer cubesat-1U which is based on PIC24FJ256GA110 microcontroller and an I2C network, in case of C&DH subsystem, the microcontroller has 16-bit feature and Microchip RISC architecture. Both are RISC microcontrollers, but from different manufacturers and therefore have a different implementation of instruction table beyond the different settings owing to internal constitution as: ● Numbering of the pins; ● Sharing pins between its peripherals; ● Number of registers for each peripherals; ● Registers designations. The reuse technique is demonstrated here by making use of the “Abstract Factory”, a pattern that fits very well in this case, because it gives the flexibility to include new microcontrollers while it also allow adding new peripherals. Note the Figure 4, where it makes use of abstract class type: one for creation of an abstract microcontroller class and another for creation of an abstract peripheral class. Therefore as an intersection of lines and columns, it will be possible to build any concrete microcontroller with either peripheral also concrete. Both microcontrollers bring in their internal constitution the TIMER peripheral, and through settings they can work as clock, counter or comparator mode, because the user will set the microcontroller and peripherals to be used and so the class "UserConfiguration" is associated to factory. São José dos Campos/SP - 23 e 24 de agosto de 2016 Figure 4 - Reuse of Internal Services Components for space projects P1, P2 and P3 5. Results Evaluation In this section, we will present some of the preliminary evaluation results expected with the techniques presented. 5.1. Productivity gains through of rework decrease In order to demonstrate the rework decreasing and therefore the gains of productivity in projects development, it will be analyzed the flow that can occur in the software development process when the library is applied. Therefore, one must note the following possible paths: a. During reuse activities of project is noted that microcontroller used does not have IswC or ISC in library and its development occurs without changes in the development process. In this case there is no gain because the microcontroller was not included in the library and cannot generate auto-codes to the driver layer or intermediate layer for project. This is a point which there is a new process to be followed, so that the team can receive its benefits in future projects. It is important to note that the development of IC is independent of the project and can be done at any time, because it is entirely dedicated to the study of microcontroller features, no matter where it will be used. Although this process can be done separately from the project process, it’s always possible do it together, but in this case we will overcharge this stage. b. During reuse activities of project is noted that microcontroller is already in the library which has totally or partially IswC needed for the project, so it is not necessary the development of drivers, and the development team will have to deal with intermediate functions and application. In this way the first gain São José dos Campos/SP - 23 e 24 de agosto de 2016 appears because when we look at the development process we see the driver development activities, as well as verification and validation tests could be eliminated as we will see forward. The activity that auto-codes generates is included in process, however it is the simplest use of the library, because the developer at this point will just generate auto-codes and load them into IDE to continue his work from above layers. c. During project reuse activities it is noted that microcontroller is already in the library which has totally or partially IswC and ISC, so that both are reused, leaving for the developer just the applications development. In this way we have the main productivity gain of the project, either for some reason it is necessary to do the microcontroller upgrade and the codes for old microcontroller was developed together with IswC and ISC of the library or because the functions from other equipment were already in the library which is expected to occur when the technique is a practice applied in the company's portfolio. 5.2. Productivity gains through parallel development When the software design is done minimizing its couplings, it is possible to improve productivity by having different teams working at the same time in the various software components. The development of the IswC library is an activity that allows decoupling in the implementation of various projects since the focus is to build drivers for a particular microcontroller regardless of application. The ISC´s are related to the project ability of reusing the same intermediate functions on other projects and this is possible through the systemic knowledge of the project. As the project capabilities and performances are defined for each subsystem, it is possible to design an ISC to it. Since a subsystem might be common to a given portfolio, some equipment also may be common to all satellites; reuse of an ISC will be high. Both IswC and ISC developments can occur regardless of the applications and within each scope IswC or ISC can be applied a parallel development. 5.3. Certification through of quality gain Currently there are methods to certify a particular software component, for instance, the Reusable Software Components - RSC from FAA. Its subsequent uses may dispense verifications and tests about its workings. The set of ISC and IswC´s as the timer component earlier shown in Figure 3 could be treated as a software component and be submitted to certification processes. Its reuse brings greater confidence to the project and may reduce scope and deadlines to the certification process once only applications are targeted. 6. Conclusion The use of proposed technique for software reuse across all levels of abstraction intended on this work focused in drives and intermediate software layers. Its practice can change the software development process as it allows the separation of the software development from its main project. São José dos Campos/SP - 23 e 24 de agosto de 2016 When this is combined with the management processes, it allows parallel developments with IswC, ISC and its applications contributing to productivity gains. It is worth mentioning that reusability has an overhead on the software development processes and should be planned. Constant changes on hardware platforms of projects decrease the reusability as it relies on software for a specific hardware platform and each change may require the development of another set of software. IswC and ISC can go through an independent certification processes and avoid re-testing. Moreover, to be economically viable, the more they are used in projects the more reliability increases and therefore, so software quality. References AC20-148 (2004), Advisory Circular – Reusable Software Components – RSC. Barbarán, G.C. and Francischini, P.G. (1998), Indicadores de Produtividade na Indústria de Software. Bauer, T.O. (2009), Produtividade no Desenvolvimento de Software. Burger, E.E. (2014), Proposta de Método para AIT de Pico e Nanossatélites. CCSDS 850.0-G-2(2013), Spacecraft Onboard Interface Services, GREEN BOOK. Dos Santos W.A. (2015), Workshop sobre Nanosats e suas Aplicações. Douglass, B.P. (2002), Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems. Specht, E. (2007), Analysis of the Use of Declarative Languages for Enhanced Embedded System Software Development. Freeman, E. (2009), Use a Cabeça – Padrões de Projetos, 2nd edition. De Oliveira, I.R (2008), Considerações sobre Reuso de Software Aviônico. Kief, C. J. and Zufelt, B.K. (2011), Trailblazer: Proof of Concept CubeSat Mission for SPA-1. Tagawa, G.B.S. and E Souza, M.L.O. (2011), An Overview of the Integrated Modular Avionics (IMA) Concept.