• Nenhum resultado encontrado

An embedded software component quality evaluation methodology

N/A
N/A
Protected

Academic year: 2021

Share "An embedded software component quality evaluation methodology"

Copied!
220
0
0

Texto

(1)Pós-Graduação em Ciência da Computação. “An Embedded Software Component Quality Evaluation Methodology”. Fernando Ferreira de Carvalho PHD THESIS. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, FEBRUARY/2010.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Fernando Ferreira de Carvalho. “An Embedded Software Component Quality Evaluation Methodology". ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE. FEDERAL. DE. PERNAMBUCO. COMO. REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE DOUTOR EM CIÊNCIA DA COMPUTAÇÃO.. A PHD. THESIS PRESENTED TO THE FEDERAL UNIVERSITY OF PERNAMBUCO IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF PHD. IN COMPUTER SCIENCE.. ADVISOR: Silvio Lemos Meira. RECIFE, FEBRUARY/2010.

(3) Carvalho, Fernando Ferreira de An embedded software component quality evaluation methodology / Fernando Ferreira de Carvalho. - Recife: O Autor, 2010. 209 p. : il., fig., tab. Tese (doutorado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2010. Inclui bibliografia e apêndices. 1. Ciência da computação. 2. Sistemas embarcados. 3. Qualidade de componentes de software. 4. Engenharia da computação. I. Título. 004. CDD (22. ed.). MEI2010 – 074.

(4)

(5) R. ESUMO. Um dos maiores desafios para a indústria de embarcados é fornecer produtos com alto nível de qualidade e funcionalidade, a um baixo custo e curto tempo de desenvolvimento, disponibilizando-o rapidamente ao mercado, aumentando assim, o retorno dos investimentos. Os requisitos de custo e tempo de desenvolvimento têm sido abordados com bastante êxito pela engenharia de software baseada em componentes (CBSE) aliada à técnica de reuso de componentes. No entanto, a utilização da abordagem CBSE sem as devidas verificações da qualidade dos componentes utilizados, pode trazer conseqüências catastróficas (Jezequel et al., 1997). A utilização de mecanismos apropriados de pesquisa, seleção e avaliação da qualidade de componentes são considerados pontos chave na adoção da abordagem CBSE. Diante do exposto, esta tese propõe uma Metodologia para Avaliação da Qualidade de Componentes de Software Embarcados sob diferentes aspectos. A idéia é solucionar a falta de consistência entre as normas ISO/IEC 9126, 14598 e 2500, incluindo o contexto de componente de software e estendendo-o ao domínio de sistemas embarcados. Estas normas provêem definições de alto nível para características e métricas para produtos de software, mas não provêem formas de usá-las efetivamente, tornando muito difícil aplicá-las sem adquirir mais informações de outras fontes. A Metodologia é composta de quatro módulos que se complementam em busca da qualidade, através de um processo de avaliação, um modelo de qualidade, técnicas de avaliação agrupadas por níveis de qualidade e uma abordagem de métricas. Desta forma, ela auxilia o desenvolvedor de sistemas embarcado no processo de seleção de componentes, avaliando qual componente melhor se enquadra nos requisitos do sistema. É utilizada por avaliadores terceirizados quando contratados por fornecedores a fim de obter credibilidade em seus componentes. A metodologia possibilita avaliar a qualidade do componente embarcado antes do mesmo ser armazenado em um sistema de repositório, especialmente no contexto do framework robusto para reuso de software, proposto por Almeida (Almeida, 2004). Palavras-chaves: Sistemas embarcados, Qualidade de componentes software,Avaliação de qualidade, Desenvolvimento baseado em component (CBD).

(6) A. bstract. One of the biggest challenges for the embedded industry is to provide products of high quality and functionality at low cost and short time-to-marketing, thus increasing the Return on Investment (RoI). The cost and development time requirements have been addressed quite successfully by component-based software engineering (CBSE) combined with component reuse technique. However, the use of CBSE approach without the quality assurance of the components used can bring catastrophic results (Jezequel et al., 1997). The use of appropriate mechanisms for search, selection and quality evaluation of components are considered key points in CBSE adoption. In this way, this thesis proposes an Embedded Software Components Quality Evaluation Methodology. Its focus is to improve the lack of consistency between the standards ISO/IEC 9126, ISO/IEC 14598, ISO/IEC 25000, also including the software component quality context and extend it to the embedded domain. These standards provide a high-level definition of characteristics and metrics for software products but do not provide ways to be used effectively, making them very difficult to apply without acquiring more knowledge from supplementary sources. The Methodology consists of four modules that complement each other in quality direction through an evaluation process, a quality model, evaluation techniques grouped by levels of quality and an embedded metrics approach. Thus, it helps the developer of embedded systems in selection of components to evaluate which component best fits in the system requirements. It is also used in third party evaluation when contractors are hired by components suppliers to achieve trust in its components. The methodology permits the evaluation of the quality of embedded component before being stored in a repository system, especially in the context of robust framework for software reuse, proposed by Almeida (Almeida, 2004). Keywords: Embedded systems, Software Component Quality, Quality Evaluation, Component-based development (CBD)..

(7) L. ist of Figures. Figure 1.1: The Robust Framework for Software Reuse. .................................... 7 Figure 1.2: The quality evaluation layer was divided of two modules................8 Figure 1.3: Detailing the quality evaluation layer in robust framework.............9 Figure 2.1: An embedded system encompasses the CPU as well as many other resources............................................................................................................... 15 Figure 2.2: Component technology for small embedded Systems ................... 17 Figure 2.3: The characteristics and its priority in automotive domain............25 Figure 3.1: SQuaRE Architecture ...................................................................... 37 Figure 3.2: ISO/IEC 25040 ...............................................................................42 Figure 3.3: Structure of Prediction-Enabled Component Technology (Wallnau, 2003). ................................................................................................................... 51 Figure 3.4: Process of obtaining, evaluating and storing components ............56 Figure 3.5: Research on embedded software component quality and certification timeline. ........................................................................................... 57 Figure 4.1: Embedded Software Component Quality Evaluation Methodology. .............................................................................................................................. 61 Figure 4.2: Flow Diagram of Embedded Software Component Quality Evaluation Methodology. .....................................................................................63 Figure 4.3: The EQP describe in Business Process Modeling ..........................66 Figure 4.4: Activities of establish evaluation requirements described in BPM. ..............................................................................................................................68 Figure 4.5: Activities of specify the evaluation described in BPM. .................. 72 Figure 4.6: Activities of evaluation design described in BPM.......................... 75 Figure 4.7: Activities of execute the evaluation described in BPM. .................78 Figure 4.8: The proposed EQM, in graphic way. ..............................................86 Figure 4.9: The EQL hierarchy........................................................................100 Figure 4.10: Different EQL for different quality characteristics. ................... 101 Figure 4.11: The Overview of GQM Paradigm .................................................112 Figure 5.1: Baud Rate Converter Evaluation Architecture. ............................ 135 Figure 5.2: Siemens ECU used to simulate the vehicle behavior. .................. 136 Figure 5.3: Develop board model LPC-P2148 Olimex.................................... 136 Figure 5.4: K-line interface board used to connect ECU and microcontroller. ............................................................................................................................ 137 Figure 5.5: Evaluation of quality characteristics: BRConverter. ................... 143 Figure 5.6: Quality in use characteristics: BRConverter................................ 143.

(8) L. ist of Tables. Table 2.1: Summary of relevant characteristics in Crnkovic’s research. .......... 21 Table 2.2: Priority classes used to classify the importance of the different quality attributes. .................................................................................................24 Table 3.1: Software quality standards. ..............................................................32 Table 3.2: IEC61131............................................................................................33 Table 3.3: DO-178B............................................................................................34 Table 3.4: Characteristics and Sub-Characteristics in SQuaRE project. .......... 41 Table 4.1: The detail of the EQP, modules, activities and steps........................65 Table 4.2: Summary of Establish Evaluation Requirements module...............68 Table 4.3: Summary of evaluation module specification.................................. 72 Table 4.4: Summary of the evaluation module design...................................... 75 Table 4.5: Summary of the evaluation module execution................................. 77 Table 4.6: The Embedded software component Quality Model and its parts ..82 Table 4.7: Summary of embedded quality characteristics research in different domain..................................................................................................................84 Table 4.8: Changes in the proposed EQM, in relation to ISO/IEC 25010. ......85 Table 4.9: Quality Attributes for sub-characteristics at Runtime and Life-cycle. .............................................................................................................................. 91 Table 4.10: 3ª Part of EQM: Additional Information. ......................................98 Table 4.11: Guidelines for selecting evaluation level. ..................................... 102 Table 4.12: Embedded Quality Level – EQL and the evaluation techniques. 104 Table 4.13: Embedded Quality Attribute X Evaluation Techniques............... 106 Table 4.14: The suggested metrics to use by quality evaluation methodology. .............................................................................................................................116 Tabela 5.1: Quality Attributes selected based in EQL I................................... 139 Tabela 5.2: Evaluation Techniques selected by evaluation staff .....................141.

(9) A. cronyms. Terms - Descriptions B2B - Business to Business CBD - Component-Based Development CBSE - Component-Based Software Engineering C.E.S.A.R. - Recife Center for Advanced Studies and Systems CMU/SEI - Carnegie Mellon University’s Software Engineering Institute COTS - Commercial Off-The-Self CBSD - Component-Based Software Development COM - Component Object Model CCM - CORBA Component Model CMM - Capability Maturity Model CMMI - Capability Maturity Model Integrated EQL - Embedded software component evaluation techniques on Quality Level EQM - Embedded software component Quality Model EQP - Embedded software component Quality Process EMA - Embedded Metrics Approach GQM - Goal Question Metric Paradigm ISO - International Organization for Standardization IEC - International Electro-technical Commission OMG - Object Management Group PECT - Prediction-Enabled Component Technology PACC - Predictable Assembly from Certifiable Components RiSE - Reuse in Software Engineering group SPICE - Software Process Improvement and Capability dEtermination UART - Universal Asynchronous Receiver Transmitter XML - eXtensible Markup Language.

(10) C 1. Introduction .................................................................1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8. 2. Motivation ..............................................................................1 Problem formulation ............................................................. 4 General Objective .................................................................. 5 Specific Objetive .................................................................... 5 Proposed solution.................................................................. 6 Out of Scope ........................................................................ 10 Statement of Contributions .................................................. 11 Organization of the Thesis....................................................12. Embedded Systems Design .........................................14 2.1 2.2 2.3 2.4. 3. ontents. Basic concepts for Component-Based embedded systems...15 Specific requirements for embedded systems ......................19 The needs and priorities in research ................................... 27 Summary ............................................................................. 29. Correlates Works and Component Quality, Evaluation. and Certification: A Survey .............................................. 31 3.1. Correlates Works..................................................................31 3.1.4.1 3.1.4.2 3.1.4.3. ISO/IEC 2501n (Quality Model Division) .......................................... 40 ISO/IEC 2504n (Quality Evaluation Division) .................................. 42 ISO/IEC 2502n (Quality Measurement Division) ............................. 42. 3.2 A Survey: Embedded Software Component Quality, Evaluation and Certification......................................................... 43 3.3 Failures in Software Component Certification.................... 53 3.4 Software Component Evaluation and Certification............. 54 3.5 Summary of the Study ......................................................... 57 3.6 Summary ............................................................................. 58 4. Embedded Software Component Quality Evaluation. Methodology ................................................................... 59 4.1 Embedded software component Quality evaluation Process (EQP) ............................................................................................ 64.

(11) 4.2. Embedded software component Quality Model (EQM).......81 4.2.1.1 4.2.1.2. Characteristics and Sub-Characteristics ............................................ 83 Quality Attributes of EQM...................................................................91. 4.3 Embedded software component evaluation techniques based on Quality Level (EQL) ............................................................... 100 4.4 Embedded Metrics Approach (EMA) ................................ 109 4.5 Summary ............................................................................125 5. The Experimental Study ........................................... 126 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11. 6. Conclusions and future works ..................................148 6.1 6.2 6.3. 7. Introduction .......................................................................126 The Experimental Study.....................................................127 The Definition ................................................................... 128 The Planning ..................................................................... 128 The project used in the experimental study .......................134 The Architecture, Environment and Scenarios ..................135 The Instrumentation ......................................................... 138 The Execution.................................................................... 138 The Analysis and Interpretation.........................................139 Lessons Learned..............................................................146 Summary ............................................................................147. Contributions .................................................................... 148 Future Work .......................................................................150 Academic Contributions..................................................... 151. References ................................................................ 152. Appendix A..................................................................... 165 Appendix B..................................................................... 178 Appendix C.....................................................................183.

(12) Chapter 1 - Introduction. 1. 1. Introduction. Embedded systems are at the heart of many electronic systems in use today. Added v0alue to products is to a large extent provided by the software. Furthermore, production cost reduction is imperative and is often achieved by introducing software that permits the use of less complex hardware. Domains in which the use of software is now essential include, among others, the automotive, medical systems, process control, and manufacturing industries. Embedded systems are often systems consisting of software and hardware. The software part incorporates many software components that must cooperate without fail. It is platform-dependent, consequently difficult to port, upgrade, and customize, and offers limited opportunities for reuse, even within a single application domain. The demands that companies in these electronic products must satisfy include low production costs, short time to market and high quality. The cost and time to market issue is addressed by means of the rapidly emerging Component-based software engineering (CBSE) approach. In CBSE, embedded systems are built as an assembly of components already developed and prepared for integration.. 1.1 Motivation A common characteristic of all systems is the increasing importance of software. For example, software development costs for industrial robots today constitute about 75% of total costs, while in car industry it is currently about 30%. Some ten to fifteen years ago this number was about 25% for robots and negligible for cars (Crnkovic, 2005)..

(13) Chapter 1 - Introduction. 2. The following sections show the main motivations that led the preparation of this work.. 1.1.1. CBSE approach and reuse technique. One of the most compelling reasons for adopting component-based approaches in embedded software design is the premise of reuse. The idea is to build software from existing components primarily by assembling and replacing interoperable parts. The implications for reduced development time and improved product quality make this approach very attractive (Krueger, 1992). In a real environment, a developer that retrieves a faulty component from the repository would certainly lose his trust in the system, becoming discouraged to make new queries. Thus, it is extremely important to assert the quality of the assets that are stored into the repository before making them available for reuse. Despite this importance, the software engineering community had not explored these issues until recently. In this way, a new research area arose: components evaluation and quality assurance (Wohlin et al., 1994), (Mingins et al., 1998), (Morris et al., 2001), (Schmidt, 2003), (Wallnau, 2003). However, several questions still remain unanswered, such as: (i). How quality evaluation should be carried out?. (ii). What are the requirements for a evaluation process? and,. (iii). Who should perform it? (Goulão et al., 2002a).. This is the reason why there is still no well-defined standard to perform component quality evaluation (Voas et al., 2000), (Morris et al., 2001). There are needs for a number of improvements in CBSE approach applied in embedded industry, following Crnkovic (Crnkovic, 2005). One of the main improvements is directly related to quality. “Component quality evaluation: In order to transfer components across organizations, techniques and procedures should be developed for ensuring the trustworthiness of components.”.

(14) Chapter 1 - Introduction. 1.1.2. 3. Software Components Market Inhibitors. The Carnegie Mellon University’s Software Engineering Institute (CMU/SEI) (Bass et al., 2000) studied industry trends in the use of software components from technical and business perspectives. A distinct set of inhibitors to adopting software component technology emerged from the conducted surveys and interviews of earlier adopters of software component technology. From this data and from the interviews, the study concludes that the market perceives the following key inhibitors for component adoption, presented here in decreasing order of importance: •. Lack of available components;. •. Lack of stable standards for component technology;. •. Lack of quality components; and. •. Lack of an engineering method to consistently produce quality systems from components. The software engineering community is already attempting to reduce the. gaps related to the two first inhibitors. However, in relation to the third inhibitor, the community effort is still an incipient. Further research is required in order to assure the production of certified components, especially when combined with the lack of component-based software engineering techniques that deliver predictable properties (the last inhibitor). Further, according to Voas (Voas, 1998), to foster an emerging software component marketplace, it must be clear for buyers whether a component’s impact is positive or negative. Ideally, buyers should have this information before buying a component. Component buyers could then choose an appropriate component according to its quality level. With this information, system builders could make better design decisions and be less fearful of liability concerns, and component vendors could expect a growing marketplace for their products..

(15) Chapter 1 - Introduction. 1.1.3. 4. The Future of Software Components. Important researches on software components, such as Heineman (Heineman et al., 2001), Councill in (Councill, 2001), Crnkovic (Crnkovic, 2005), Wallnau (Wallnau, 2003), Wallnau (Wallnau, 2004), Schneider & Han (Schneider & Han, 2004) and Andreou & Tziakouris (Andreou & Tziakouris, 2007) indicates that the future of software components is quality evaluation and certification. These authors state that to know the component quality is a necessary precondition for CBSE to be successfully adopted and to achieve the associated economic and social benefits that CBSE could yield. With the success of CBSE, software developers will have more time to develop, instead of spending their time addressing problems associated with understanding and fixing someone else’s code. Qualified components used during development will have predetermined and well established criteria, thus reducing the risk of system failure and increasing the likelihood that the system will comply with design standards.. 1.2 Problem formulation The previous section stated that designers increasingly often build systems using reusable components due to the complexity of their designs. Therefore, there is an increasing need to efficiently and effectively qualify such systems. Quality assurance which can effectively cope with this situation and take advantage of the component-based structure needs to be developed. The evaluation of the quality of components (i.e. the assessment of their quality attributes) needs to be done by independent parties, at least until software vendors acquire the level of maturity that hardware vendors currently have. The software industry still far from counting with the hardware data sheets and catalogues available for hardware components that describe all their characteristics. However, it is necessary to have them for software components too if it wants to talk about a “real” Component-based Software Engineering. Many organizations struggle in their attempts to select and evaluate an appropriate component in their system. For this reason, a well-defined and consistent software component quality assurance is essential for to transfer.

(16) Chapter 1 - Introduction. 5. components across organizations and the component market adoption (i.e. without an efficient mechanism to select/evaluate the component quality). However, the main drawback of the existing international standards is that they provide very generic definition, quality models, guidelines, and address only software product’s quality issues, which are very difficult to apply to specific domains such as embedded components and CBSE. In a survey of the state-of-the-art (Carvalho et al., 2009b) was noted that there is a lack of processes, methods, techniques and tools available for evaluating component quality, specifically for embedded domain. This necessity is pointed out by different researchers (Voas, 1998), (Morris et al., 2001), (Wallnau, 2003), (Alvaro et al., 2005), (Bass et al., 2003), (Softex, 2007) and (Lucrédio et al., 2007). Most researchers agree that component quality is an essential aspect of the CBSE adoption and software reuse success. This thesis address in the following problem: “The lack of mechanisms, process, methods and guidelines to support the quality evaluation for software component in embedded systems domain.”. 1.3 General Objective Provide an environment that supports the quality evaluation for software components which will be used to develop embedded systems. Allowing designers better knowledge of the quality of components to be used in the system under development through a quality report component, which will provide detailed information about the component quality under different viewpoints. In this environment the designer can evaluate different components and verify which best fits the system requirements under development.. 1.4 Specific Objetive The proposed methodology’s main objectives are:.

(17) Chapter 1 - Introduction i.. 6. Serve as a tool for components acquirers or developers, helping them in the components selection to see which component best fits the system requirements to be built;. ii.. To be used in third party evaluation when contractors are hired by component suppliers in order to achieve trust in its components in industry;. iii.. To enable the quality evaluation of embedded component before being stored in a repository system for reuse purpose, especially in the context of robust framework for software reuse, proposed by Almeida (Almeida, 2004).. 1.5 Proposed solution This thesis defines an Embedded Software Component Quality Evaluation Methodology, which includes a quality evaluation process, the steps of definition of embedded quality model, evaluation techniques based on quality level and an embedded metrics approach. The methodology is based on a set of modules, activities, steps and guidelines. Moreover, the process is based on the state-of-the-art in the area and its foundations and elements are discussed in details. In this way, the main goals of this thesis were to define Embedded Software Component Quality Evaluation Methodology that is composed of four inter-related modules in order to assure the component quality degree. This methodology was proposed with basis in the standards ISO/IEC 25010, ISO/IEC 9126, ISO/IEC 14598 adapted for component context and embedded domain. Different from other approaches in the literature (Goulão et al., 2002b), (Beus-Dukic et al., 2003), (Cho et al., 2001), (Gui and Scott, 2007) that provide only isolated aspects to assure the component quality, this thesis tries to investigate and make available a complete methodology with all necessary mechanisms to execute the component evaluation activities. Through these evaluations it is expected a continuous evolution of the whole methodology in a way that the software industry can start to trust in it and evaluate its own embedded software components..

(18) Chapter 1 - Introduction. 7. Moreover, this thesis is a part of a big project, a robust framework for software reuse (Almeida et al., 2004), in order to establish a standard for component development; to develop a repository system; and to develop a general purpose and embedded software component quality evaluation process. In order to generate a well-defined model for developing, evaluating quality, storing and, subsequently, making it possible for embedded system industry or software factories to reuse software components. This project has been developed. in. collaboration. between. the. academia. (UFPE) and industry (C.E.S.A.R.7). The RiSE group8 is the link between these parts.. Figure 1.1: The Robust Framework for Software Reuse. However, to better support the embedded domain and our specific quality characteristics, the component quality evaluation was divided into two parts, as shown the Figure 1.2. The first of these, focuses on general purpose software component evaluation, in general, the software component used in IBM-PC compatible. The other, is a component quality evaluation that aligns to. 7 8. Recife Center for Advanced Studies and Systems, http://www.cesar.org.br. Reuse in Software Engineering (RiSE) group – http://www.rise.com.br..

(19) Chapter 1 - Introduction. 8. specific requirements and constraints to develop quality characteristics for embedded domain. The framework (Figure 1.1) that is being developed has two layers. The first layer (on the left) is composed of best practices related to software reuse. Non-technical. factors,. such. organizational. management. as are. education, considered.. training, This. incentives,. layer. and. constitutes. a. fundamental step prior to the introduction of the framework in the organizations. The second layer (on the right) is composed of important technical aspects related to software reuse, such as processes, environments, tools, and a evaluation process, which is the focus of this thesis. In order to achieve the main objective, the process is based on the following foundations:. Figure 1.2: The quality evaluation layer was divided of two modules. First, the correct usage of methodology should follow a well-defined and controllable evaluation process. After, there must be defined an embedded quality reference model. There must be a series of techniques that allow one to evaluate whether a component conforms to the reference model in.

(20) Chapter 1 - Introduction. 9. different levels of quality. Finally, a set of metrics are needed, in order to track the components properties and the enactment of the evaluation process. These four main modules: •. Embedded software component Quality evaluation Process, (EQP) ;. •. Embedded software component Quality Model (EQM);. •. Embedded software component evaluation techniques based on Quality Level (EQL) ; and,. •. Embedded Metrics Approach (EMA). These are the modules of an Embedded Software Component Quality. Evaluation Methodology (Figure 1.3) that is being investigated as a part of the RiSE project.. Figure 1.3: Detailing the quality evaluation layer in robust framework..

(21) Chapter 1 - Introduction. 10. The methodology will allow that the components produced in a Software Reuse Environment have assured quality before being stored on a Repository System. In this way, software engineers would have a greater degree of trust in the components that are being reused.. 1.6 Out of Scope As the proposed reuse process is part of a broader context, a set of related aspects will be left out of its scope. Nevertheless, as these aspects were envisioned since the initial definitions of the process, they can be added in the future with some adjustments. Thus, the following issues are not directly addressed by this work: •. Cost Model: Cost estimation is a key requirement for CBSD before the actual development activities can proceed. Cost is a function of the enterprise itself, its particular development process, the selected solution, and the management and availability of the resource during the development project (Cechich et al., 2003), (Mahmooda et al, 2005). A cost model is useful to help the software engineer during the analysis of the software component available to purchase (or to select or to evaluate). However, it makes sense when, first, you have defined processes, methods, techniques and tools to execute the selection and/or the evaluation task in order to identify the cost/benefit to purchase or to evaluate a component.. •. Formal Proof: Meyer (Meyer, 2003) and Karlsson (Karlsson, 2006) proposes a formal approach in order to acquire trust in software components. His idea is to build or to use software components with fully proved properties or characteristics. The intention is to develop software components that could be reliable to the software market. This thesis does not consider cost model because the whole methodology. that is the basis for embedded software component evaluation will be considered in this first moment and, after that a cost model to help organizations to define if it is viable evaluate certain kinds of components (or not) will be useful. The formal quality assurance is not considered mainly.

(22) Chapter 1 - Introduction. 11. because the software component market is not inclined to formally specify their software components. This kind of approach is highly expensive, in terms of development time and level of expertise that is needed, and component developers still do not know if it is cost effective to spend effort in this direction without having specific requirements such as strict time constraints or high reliability. However, the Embedded software component evaluation techniques based on Quality Level (EQL) provides formal proof evaluation techniques that could be useful in some scenarios, depending of the customer’s necessities and the cost/benefit to do so;. 1.7 Statement of Contributions As a result of the work presented in this thesis, the following contributions can be enumerated: •. An extensive study of the key developments in the field of quality, evaluation and certification of embedded software component, in an attempt to analyze this research area and identify trends to follow;. •. A survey of the state-of-the-art of quality, evaluation and certification of general purpose and embedded software component in order to understand and identify the weak and strong points of existing processes (Carvalho et al., 2009a), (Carvalho et al., 2009b);. •. Definition of the Embedded software component Quality Model (EQM) (Carvalho et al., 2009c), (Carvalho et al., 2009d), based on the new standard, the Software Product Quality Requirements and Evaluation (SQuaRE) project (ISO/IEC 25000, 2005), Component Quality Model (CQM) (Alvaro et al., 2006) and Bertoa Quality Model (Bertoa et al., 2002);. •. Development of the Embedded software component evaluation Techniques based in Quality Level (EQL) in order to provide different thoroughness levels of evaluation techniques and a set of guidelines for selecting those evaluation levels (Carvalho et al., 2009e), (Carvalho et al., 2009f);.

(23) Chapter 1 - Introduction •. Development. 12 of. the Embedded software component. Quality. evaluation Process (EQP) in order to provide a high quality and consistent evaluation process (Carvalho et al., 2009g); •. Development of the Embedded Metrics Approach based in Goal Question Metric that is composed of a set of valuable measures to be considered as starting point during the component evaluations (Carvalho et al., 2009g); and. •. Development. of. an Embedded. Software Component. Quality. Evaluation Methodology aiming to provide a complementary mechanism to standards ISO/IEC to evaluate the embedded software component quality (Carvalho et al., 2009g).. 1.8 Organization of the Thesis The remainder of this thesis is organized as follows. Chapter 2 presents a brief overview of embedded system design, component-based development areas and requirements for embedded in different domain. The main concepts of these topics are considered. Chapter 3 presents, in the first part, the survey of the state-of-the-art of the embedded software component quality, evaluation and certification area that was performed. The failure cases that can be found in the literature are also described in this chapter. Subsequently, in the final part, this chapter describes the aspects related to the software quality, evaluation and certification concepts and standardization. The intention is to show that software reuse depends on quality. Chapter 4 presents the Embedded Software Component Quality Evaluation Methodology proposed and its related modules. Session 4.1 presents the Embedded software component Evaluation Process (EQP), describing all activities and steps that should be followed to execute the component evaluation activity in a more controllable way. Session 4.2 describes the proposed Embedded. software. component. Quality. Model. (EQM),. showing. its. characteristics, its sub-characteristics, the quality attributes that are related to the model. Session 4.3 presents the Embedded software component evaluation.

(24) Chapter 1 - Introduction. 13. techniques on Quality Level (EQL) that is composed of a set of evaluation techniques grouped by quality levels in order to provide flexibility to the component evaluation. Further, a set of guidance is delineated to direct the evaluation staff during the selection of levels. Session 4.4 presents the Embedded Metrics Approach and the paradigm adopted to define the metrics is also presented. A set of metrics usage group by quality level are presented. The Experimental Study will be shown in Chapter 5 to demonstrate the feasibility and practicality through an example of real world application. All activities of the evaluation process were developed and, at the end, the results were interpreted, summarized and an experimental conclusion is done relating the strengths and weaknesses. The conclusions of the developed work and the analysis of the proposed methodology are shown in Chapter 6, as well as contributions to academia and industry. The enhancements and features that were not addressed or developed in this work were listed in the topic further work. The papers reviewed and used as inputs for the development of this thesis are listed alphabetically in Chapter 7 as references. Three appendices were added at the end of this thesis. Appendix A shows the step by step instructions for performing a quality evaluation using the methodology proposed. The Appendix B shows the evaluator’s feedback in the use of the methodology for quality evaluation of the embedded software components,. showing. the. strengths. and. weaknesses. found. in. the. implementation and evaluation. Appendix C details the process and results achieved in the BRConverter evaluation, which was used in the experimental study reported in Chapter 5..

(25) Chapter 2 - Embedded Systems Design. 2. 14. Embedded Systems Design. Embedded systems comprise a scale from ultra small devices with simple functionality, through small systems with sophisticated functions, to large, possibly distributed systems, where the management of the complexity is the main challenge. An embedded system may be represented by a dedicated processor surrounded by dedicated hardware systems, performing very specific tasks (Junior et al., 2004a). Further, it can distinguish between systems produced in large quantities, in which the low production costs are very important and low-volume products in which the system dependability is the most important feature. All these different requirements have an impact on feasibility, on use, and on approach in component-based development. A common characteristic of all systems is increasing importance of software. For example, software development costs for industrial robots currently constitute about 75% of total costs, while in car industry it is currently about 30%. Some ten, fifteen years ago this number was about 25% for robots and negligible for cars (Crnkovic, 2005). A second common characteristic is increasing interoperability. While previously the embedded systems were mainly used for controlling different processes, today they are integrated with information systems of infotainment technologies. In this chapter, a short overview of embedded systems design will be shown..

(26) Chapter 2 - Embedded Systems Design. 15. Figure 2.1: An embedded system encompasses the CPU as well as many other resources.. 2.1 Basic concepts for Component-Based embedded systems In classic engineering disciplines a component is a self contained part or subsystem that can be used as a building block in the design of a system. In software engineering, there are many different suggestions for precise definitions of components in component based software development. The best accepted understanding of component in the software industry world is based on Szyperski’s definition (Szyperski et al. 1998). From this definition it can be assumed that a component is an executable unit, and that deployment and composition can be performed at run-time. In the domains of embedded systems this definition is largely followed, in particular the separation between component implementation and component interface. A component can be delivered in a form of a source code written in a high-level language, and allows build-time (or design-time) composition. This more liberal view is partly motivated by the embedded systems context, as will be discussed below. Many important properties of components in embedded systems, such as timing and performance, depend on the characteristics of the underlying hardware platform. Kopetz and Suri (Kopetz & Suri et al., 2003) propose to distinguish between software components and system components. Extra-.

(27) Chapter 2 - Embedded Systems Design. 16. functional properties, such as performance, cannot be specified for a software component in isolation. Such properties must either be specified with respect to a given hardware platform, or be parameterized on (characteristics of) the underlying platform. A system component, on the other hand, is defined as a self-contained hardware and software subsystem, and can satisfy both functional and extra functional properties.. 2.1.1. Component-based approach for small embedded systems. The specific characteristics of embedded systems lead to specific requirements of component technologies. In particular the approaches in development process and component specifications using interfaces are different from those implemented in the component technologies widely used in other domains. The component interface summarizes the properties of the component that are externally visible to the other parts of the system. As for embedded systems non-functional properties are as important as functional there is a tendency to include specification of extra-functional properties in the component interface (for example timing properties). This allows more system properties to be determined when the system is designed, i.e. such interface enables verification of system requirements and prediction of system properties from properties of components. In general-purpose component technologies, the interfaces are usually implemented as object interfaces supporting polymorphism by late binding. While late binding allows connecting of components that are completely unaware of each other beside the connecting interface, this flexibility comes with a performance penalty and increased risk for system failure. Therefore the dynamic component deployment is not feasible for small embedded systems, for reasons of performance, confiability and limited resources. Taking into account all the constraints for real-time and embedded systems, we can conclude that there are several reasons to perform component deployment and composition at design time rather than run-time (Crnkovic & Larsson, 2002). This allows composition tools to generate a monolithic.

(28) Chapter 2 - Embedded Systems Design. 17. firmware for the device from the component-based design and in this way achieve better performance and better predictability of the system behavior. This also enables global optimizations, e.g., in a static component composition known at design time, connections between components could be translated into direct function calls instead of using dynamic event notifications. Finally, verification and prediction of system requirements can be done statically from the given component properties. This implies that the component-based characteristic is mostly visible at design time. To achieve an efficient development process tools should exist which will provide support for component composition, component adaptation and static verification and prediction of system requirements and properties from the given component properties. There may also be a need for a run-time environment, which supports the component methodology by a set of services. The methodology enables component intercommunication (those aspects which are not performed at design time), and (where relevant) control of the behavior of the components. Figure 2.1 shows different environments in a component life cycle. The figure is adopted from (Crnkovic & Larsson, 2002).. Figure 2.2: Component technology for small embedded Systems. 2.1.2. Component-based approach for large embedded systems. For large embedded systems the resource constraints are not the primary concerns. Complexity and interoperability play a much more important role. Also due to complexity, the development of such systems is very expensive and cutting the development costs is highly prioritized. For this reason generalpurpose component technologies are of more interest than in the case for small systems..

(29) Chapter 2 - Embedded Systems Design. 18. The technology mostly used in large systems is Microsoft COM and recently .NET, and to a smaller extent different implementations of CORBA, although none of these technologies provides support for real-time. The systems using these technologies belong to the category of soft-real time systems. Often a component technology is used as a basis for additional abstraction level support, which is specified either as standards or proprietary solutions. The main reason for wide use of component-based technology is the possibility of reusing solutions in different ranges of products, efficient development tools, standardized specifications and interoperation, and integration between different products. One successful example of the adoption of a component-based technology is the initiative OPC Foundation (OLE process control Foundation, www.opcfoundation.org), an organization that consists of more than 300 member companies worldwide, it is responsible for a specification that defines a set of standard interfaces based upon Microsoft’s OLE/COM and recently .NET technology. OPC consists of a standard set of interfaces, properties, and methods for use in process-control and manufacturing-automation applications. OPC provides a common interface for communicating with diverse processcontrol devices, regardless of the controlling software or devices in the process. The application of the OPC standard interface makes possible interoperability between. automation/control. applications,. field. systems/devices. and. business/office applications. Another example of a component-based approach is development and use of the standard IEC 61131 (ISO/IEC 61131-3, 1995). IEC 61131 defines a family of languages that includes instruction lists, assembly languages, structured text, a high level language similar to Pascal, ladder diagrams, or function block diagrams (FBD). Function blocks can be viewed as components and interfaces between blocks are released by connecting in-ports and outports. Function lock execution may be periodic or event-driven. IEC 61131 has been successfully used in development of industrial process automation systems for many years..

(30) Chapter 2 - Embedded Systems Design. 19. Large embedded systems that must fulfill real-time requirements usually do not use general-purpose component-based technologies. However in some cases, such as for ABB controllers, a reduced version of COM has been used on top of a real-time operating system (Lüders et al., 2002). The reused version includes facilities for component specification using the interface description language (IDL), and some basic services at run-time such as component deployment has been used. These services have been implemented internally. Different communication protocols and I/O drivers have been identified as components.. 2.2 Specific requirements for embedded systems Embedded systems vary from very small systems to very large systems. For small systems there are strong constrains related to different recourses such as power or memory consumption and others. In most of the cases, embedded systems are real-time systems. For these as well as for large embedded systems the demands on reliability, functionality, efficiency and other characteristics that depends on domain or application. Finally, in many domains, the product life cycle is very long – in can stretch to several decades. All these characteristics have strong implications on requirements. Most of the requirements of embedded systems are related to non-functional characteristics, generally designated as extra-functional properties or quality attributes. Unfortunately, the priority quality attributes vary according to domain application. These properties can be classified in run-time and life cycle extra-functional properties. In this way, research developed by Crnkovic (Crnkovic, 2005) lists four main characteristics that must be considered to embedded systems, as shown the Table 2.1, they are listed below: (i) Real-time properties: a violation of time requirements even of a proper functional response violates the system functionality. The realtime properties: a - Response time or latency, b - Execution time, c - Worst case execution time, d - Deadline..

(31) Chapter 2 - Embedded Systems Design. 20. (ii) Dependability is defined as an ability of a system to deliver a service that can justifiably be trusted and an ability of a system to avoid failures that are more severe and frequent than is acceptable to the users (Crnkovic, 2005). The main means to attain dependability are related to avoidance of faults: fault prevention, fault tolerance, fault removal and fault forecasting and it is characterized by several attributes (Avižienis et al., 2001): a - Reliability, b - Availability, c- Integrity, d- Safety, e -Confidentiality f - Maintainability. (iii) Resource consumption. Many embedded systems have strong requirements for low and controlled consumption of different resources. The reasons may be the size of the systems and/or the demands on lower production costs. Examples of such restrictions and constraints are: a - Power consumption, b - Memory consumption, c - Execution (CPU) time, d - Computation (CPU) power. (iv) Life cycle properties. In many domains the embedded systems have very long life time running round the clock year after year. During the lifetime of a system several generations of hardware and software technologies can be used. The long life systems must be able to cope with these changes introduced either into the surrounding environment or into the systems themselves. In this way, the research concludes that many of the most important requirements of the embedded systems are related to extra-functional properties. This implies that development and maintenance of such systems are very costly. In particular activities related to verification and guaranteed behavior (formal verification, modeling, tests, etc.) and maintenance (adaptive maintenance, debugging, regressive testing, etc.) require a lot of effort. For.

(32) Chapter 2 - Embedded Systems Design. 21. these reasons the technologies and processes that lead to lower costs for these activities are very attractive and desirable. Table 2.1: Summary of relevant characteristics in Crnkovic’s research. Characteristics. Sub-characteristics. Real-time properties. Response time or latency execution time worst case execution time deadline. Dependability. Reliability Availability integrity confidentiality safety. Resource consumption. Power consumption computation (CPU) power memory Consumption execution (CPU) time,. Life cycle properties. 2.2.1. maintainability. Industrial Automation. Typical application domains of industrial automation are in control of industrial processes, power supply, and industrial robots. Industrial automation domain comprises a large area of control, monitoring and optimization systems. They typically include large pieces of software that have been developed over many years (often several decades). Most control systems are manufactured in rather large volumes, and must to a large extent be configurable to suit a variety of customer contexts. They can be classified according to different levels of control (Crnkovic & M. Larsson, 2002): (i) Process level (for example, a valve in a water pipeline, a boiler, etc.), (ii) Field level that concerns sensors, actuators, drivers, etc. (iii) Group control level that concerns controller devices and applications which control a group of related process level devices in a closed-loop fashion,.

(33) Chapter 2 - Embedded Systems Design. 22. (iv) Process control level i.e. operator stations and processing systems with their applications for plant-wide remote supervision and control and overview the entire process to be controlled, (v) Production or manufacturing management level that includes systems and applications for production planning. Notice that, even if the higher levels are not embedded, they are of uttermost importance as they need to be interoperable with the lower level which greatly influences the possible choices of the component model and in fine the design choices. The integration requirements have in many cases led to a decision to use component technologies which are not appropriate for embedded systems but provide better integration possibilities. Depending on the level, the nature of the requirements and the implementation will be quite different. In general, the lower the level, the stronger are the real-time requirements. (including. timing. predictability). and. the. resource. limitations. Also, the component based approach will include different concepts at different levels. The most important quality attributes in industrial automation, following the researchers, is: (i) lowest levels: a - Availability, b - Timeliness, c - Reliability (ii) higher levels: a - Performance, b - Usability, and c - Integrability.. 2.2.2. Automotive. To provide a domain specific classification of the importance of quality attributes for software in vehicles, and discusses how the attributes could be facilitated by a component technology. Åkerholm (Åkerholm et al., 2005) executed a research in main vehicle industries. The research method is divided into three ordered steps:.

(34) Chapter 2 - Embedded Systems Design. 23. 1 - During the first step a list of relevant quality attributes was gathered; 2 - In the next step technical representatives from a number of vehicular companies placed priorities on each of the attributes in the list reflecting their companies view respectively; 3 - Finally a synthesis step was performed, resulting in a description of the desired quality attribute support in a component technology for vehicular systems. The list of quality attributes have been collected from different literature trying to cover qualities of software that interest vehicular manufactures. In order to reduce a rather long list, attributes with clear similarities in their definitions have been grouped in more generic types of properties, e.g., portability and scalability are considered covered by maintainability. Although such grouping could fade the specific characteristics of a particular attribute, it put focus on the main concerns. In the ISO/IEC 9126 standard (ISO/IEC 9126, 2001), 6 quality attributes (functionality, reliability, usability, efficiency, maintainability, and portability) are defined for evaluation of software quality. However, the standard has not been adopted fully in this research; it is considered too brief and does not cover attributes important for embedded systems (e.g., safety, and predictability). Furthermore, concepts that sometimes are mixed with quality attributes (for example fault tolerance) are not classified as quality attributes, rather as methods to achieve qualities (as for example safety). Finally, functionality is of course one of the most important quality attributes of a product, indicating how well it satisfies stated or implied needs. However, it focuses on quality attributes beyond functionality often called extrafunctional or non-functional properties. The resulting list of quality attributes is presented below. Having been presented with the basic characteristics of quality attributes related to component technologies tailored for vehicular systems below: 1. Safety 2. Reliability 3. Predictability 4. Usability 5. Extendibility.

(35) Chapter 2 - Embedded Systems Design. 24. 6. Maintainability 7. Efficiency 8. Testability 9. Security 10. Flexibility Representatives from the technical staff of several companies have been requested to prioritize a list of quality attributes, reflecting each of the respective companies’ view. The attributes have been grouped by the company representatives in four priority classes as shown in Table 2.2 The nature of the quality attributes imply that no quality attributes can be neglected. It is essential to notice that placing an attribute in the lowest priority class (4) does not mean that the company could avoid that quality in their software, rather that the company does not spend extra efforts in reaching it. The following companies have been involved in the classification process: •. Volvo Construction Equipment. •. Volvo Cars. •. Bombardier Transportation. •. Scania. •. ABB Robotics. Table 2.2: Priority classes used to classify the importance of the different quality attributes. Priority. Description. 1. very important, must be considered. 2. important, something that one should try to consider. 3. less important, considered if it can be achieved with a small effort. 4. Unimportant, do not spend extra effort on this. As the last step the authors provide a discussion where we have combined the collected data from the companies with the classification of how to support different quality attributes in (Larsson, 2004). The combination gives an abstract description of where, which, and how different quality attributes should.

(36) Chapter 2 - Embedded Systems Design. 25. be supported by a component technology tailored for usage in the vehicular industry.. Figure 2.3: The characteristics and its priority in automotive domain. Y-axis: priority of quality attributes in a scale 1 (highest), to 4 (lowest). Xaxis: the attributes, with the highest prioritized attribute as the leftmost, and lowest as rightmost. Each of the companies has one bar for each attribute, textured as indicated below the X-axis.. 2.2.3. Medical. Wijnstra (Wijnstra, 2001) described their experience with quality attributes and aspects in the development of a medical imaging product family. To meet such requirements for a range of medical imaging products, a product family has been defined. Wijnstra distinguished between quality attributes and aspects as views. A quality attribute of an artifact is an observable property of the artifact. A quality attribute can be observable at development-time or at runtime. Following Wijnstra, quality attributes and aspects are used to add structure to the various phases of the development process. They form a supporting means for achieving completeness, i.e. have all relevant concerns been taken into account? In a product family context where the family members are constructed from a component-based platform, it is especially useful to.

(37) Chapter 2 - Embedded Systems Design. 26. achieve aspect-completeness of components, allowing system composition without worrying about individual aspects. Software architecture is defined as “the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them”. The architecture must accommodate the quality attributes as imposed on the system, which can be handled via structures in the high-level architecture, aspects, or rules & guidelines. The most characteristic and important quality attributes found in Wijnstra’s research for the medical imaging product family is given below: 1. Reliability 2. Safety 3. Functionality 4. Portability 5. Modifiability a. Configurability b. Extensibility and Evolvability 6. Testability 7. Serviceability. 2.2.4. Consumer Electronics. Consumer electronics products, such as TV, VCR, and DVD, are developed and delivered in form of product families which are characterized by many similarities and few differences and in form of product populations which are sets of products with many similarities but also many differences. Production is organized into product lines -this allows many variations on a central product definition. A product line is a top-down, planned, proactive approach to achieve reuse of software within a family or population of products. It is based on use of a common architecture and core functions included into the product platform and basic components. The diversity of products is achieved by inclusion of different components. Because of the requirements for low hardware and.

(38) Chapter 2 - Embedded Systems Design. 27. production costs, general-purpose component technologies have not been used, but rather more dedicated and simpler propriety models have been developed. An example of such a component model is the Koala component model used at Philips (Ommering et al., 2000), (Ommering, 2002). Koala is a component model and an architectural description language to build a large diversity of products from a repository of components. Koala is designed to build consumer products such as televisions, video recorders, CD and DVD players and recorders, and combinations of them.. 2.2.5. Other domains. There are many domains in which embedded systems are used extensively. Some of them are: Telecommunication, avionics and aerospace, transportation, computer games, home electronics, navigation systems, etc. While there are many similarities between these domains there are also very different requirements for their functional and extra-functional properties. The consequences are that the requirements for component-based technologies are different, and consequently it expects to have one component model that summarizes all quality attributes in common in different domains. The expectations are that only one embedded quality component models will exist, some common characteristics, such as basic principles of component specifications through interfaces, basic composition and run-time services, certain patterns, and similar.. 2.3 The needs and priorities in research The component-based approach on system level, where hardware components are designed with embedded software, has been successfully used for many years. Also large-grain generic components like protocol stacks, RTOSs, etc. have been used for a long time. In addition to this, technology supporting a component-based approach has been developed; either in the form of proprietary component models, or by using reduced versions of some widely used component models. Still, there are needs for a number of improvements. Some of them are the following (differently important for different domains):.

(39) Chapter 2 - Embedded Systems Design. 28. - There is a lack of widely adopted component technology standards which are suitable for embedded systems. For smaller-size embedded systems, it is important that a system composed of components can be optimized for speed and memory consumption, which is still missing in most of the component technologies available today. - There is also a need for interoperability between different component technologies. Specification technology is not sufficiently developed to guarantee a priori component interoperability. - Most current component technologies do not support important extrafunctional properties - There is a need for generic platform services, for, e.g., security and availability. - Tools that support component based development are still lacking - There is a lack of efficient implementations of component methodologies (i.e., middleware), which have low requirements on memory and processing power. Major needs for the further development of component technology for embedded systems are the following (Brinksma et al., 2001). - Need for adopted component models and methodologies for embedded systems. A problem is that many application domains have applicationdependent requirements on such a technology. - Need for light-weight implementations of component methodologies. In order to support more advanced features in component-based systems, the runtime platform must provide certain services, which however must use only limited resources. - Obtaining extra-functional properties of components: Timing and performance. properties. are. usually. obtained. from. components. by. measurement, usually by means of simulation. Problems with this approach are that the results depend crucially on the environment (model) used for the measurements may not be valid in other environments, and that the results may depend on factors which cannot easily be controlled. Techniques should be developed for overcoming these problems, thereby obtaining more reliable specifications of component properties..

(40) Chapter 2 - Embedded Systems Design. 29. - Platform and vendor independence: Many current component technologies are rather tightly bound to a particular platform (either run-time platform or design platform). This means that components only make sense in the context of a particular platform. - Efforts to predict system properties: The analysis of many global properties from component properties is hindered by inherent complexity issues. Efforts should be directed to finding techniques for coping with this complexity. - Component certification: In order to transfer components across. organizations,. techniques. and. procedures. should. be. developed for ensuring the trustworthiness of components. - Component noninterference: Particularly in safety critical applications, there is a need to ensure separation and protection between component implementations, in terms of memory protection, resource usage, etc. - Tool support: The adoption of component technology depends on the development of tool support. The clearly identified priorities of CBSE for embedded systems are: - Predicting system properties. A research challenge today is to predict system properties from the component properties. This is interesting for system integration, to achieve predictability, etc. - Development of widely adopted component models for real-time systems. Such a model should be supported by technology for generating necessary runtime infrastructure (which must be light-weight), generation of monitors to check conformance with contracts, etc.. 2.4 Summary At the beginning of the chapter the basic concepts about embedded system are defined. After that, the component-based software development (CBSD) approach and features that are relevant to these systems are described. First, the focus was on small embedded systems, showing the specific constraints of these systems. In the second phase the characteristics and limitations of large embedded systems were discussed..

(41) Chapter 2 - Embedded Systems Design. 30. In the second part of this chapter the search results in the literature of the main quality characteristics that involve embedded systems in different application areas were presented, including:  Industrial Automation  Automotive  Medical  Electronics Consumer  General This research was of great importance to the work, because the quality characteristics that make up the quality reference model, which will be shown in Chapter 4 of this thesis, was based on this survey. Finally, the chapter ends by listing the needs and priorities in research into the use of the component-based development (CBD) approach for embedded systems. The list was constructed by reports in the literature by several researchers in the field of embedded systems..

(42) Chapter 3 – Correlates Works and Component Quality, Evaluation and Certification. 3. Correlates Works and Component Quality, Evaluation and Certification: A Survey. This Chapter presents the correlates works and a survey of cutting edge embedded software component quality, evaluation and certification research, in an attempt to analyze the trends in CBSE/CBD applied embedded systems projects and to probe some of the component quality, evaluation and certification research directions.. 3.1 Correlates Works One of the main objectives of software engineering is to improve the quality of software products, establishing methods and technologies to build software products within given time limits and available resources. Given the direct correlation that exists between software products and processes, the quality area could be basically divided into two main topics (Pressman, 2005): •. Software Product Quality: aiming to assure the quality of the generated product (e.g. ISO/IEC 9126 (ISO/IEC 9126, 2001), ISO/IEC 12119 (ISO/IEC 12119, 1994), ISO/IEC 14598 (ISO/IEC 14598, 1998), SQuaRE project (ISO/IEC 25000, 2005) (McCall et al., 1977), (Boehm et al., 1978), among others); and. •. Software Processes Quality: looking for the definition, evaluation and improvement of software development processes (e.g. Capability Maturity Model (CMM) (Paulk et al., 1993), Capability Maturity Model Integrated (CMMI) (CMMI, 2000), Software Process Improvement and Capability dEtermination (SPICE) (Drouin, 1995), among others). Currently, many institutions are concerned with creating standards to. properly evaluate the quality of the software product and software development. 31.

(43) Chapter 3 – Correlates Works and Component Quality, Evaluation and Certification processes. In order to provide a general vision, Table 3.1 shows a set of national and international standards in embedded domain. Table 3.1: Software quality standards. Standards. Overview. ISO/IEC 61131. component-based approach for industrial systems. RTCA DO 178B. guidelines for development of aviation software. ISO/IEC 61508. Security Life cycle for industrial software. ISO/IEC 9126. Software Products Quality Characteristics. ISO/IEC 14598. Guides to evaluate software product, based on practical usage of the ISO 9156 standard. ISO/IEC 12119. Quality Requirements and Testing for Software Packages. SQuaRE project. Software Product Quality Requirements and Evaluation. (ISO/IEC 25000) IEEE P1061. Standard for Software Quality Metrics Methodology. ISO/IEC 12207. Software Life Cycle Process.. NBR ISO 8402. Quality Management and Assurance.. NBR ISO 9000-1-2. Model for quality assurance in Design, Development, Test, Installation and Servicing. NBR ISO 9000-3. Quality Management and Assurance. Application of the ISO 9000 standard to the software development process (evolution of the NBR ISO 8402).. CMMI. SEI’s model for judging the maturity of the software. (Capability. processes of an organization and for identifying the key. Maturity Model. practices that are required to increase the maturity of. Integration). these processes.. ISO 15504. It is a framework for the assessment of software processes.. The embedded software market has grown in the decade, as well as the necessity of producing software with quality and trust. Thus, obtaining quality certificates has been a major concern for software companies. In 2002, Weber (Weber et al., 2002) showed how this tendency influenced the Brazilian software companies from 1995 until 2002. The number of companies looking for standards to assure the quality of their products or processes has grown drastically in the recent past. The graph on the left shows this growth in relation to ISO 9000, which assures the Quality. 32.

(44) Chapter 3 – Correlates Works and Component Quality, Evaluation and Certification Management and Assurance. The graph on the right shows this growth in relation to CMM, which assures the software development processes quality. However, there is still no standard or effective process to certify the quality of pieces of embedded software, such as components. As shown in Chapter 1, this is one of the major inhibitors to the adoption of CBD. However, some ideas of software product quality assurance may be seen in the SQuaRE project (described next), which will be adopted as a basis for defining a consistent quality methodology for embedded software components.. 3.1.1. ISO/IEC 61131. IEC 61131 was developed by the International Electro-technical Commission with the input of vendors, end-users and academics, to provide a generic programming environment for the industry. IEC 61131 consists of five parts listed below, in Table 3.2. Table 3.2: IEC61131 Part. Title. Part 1. General information. Part 2. Equipment and test requirements. Part 3. PLC programming languages. Part 4. User guidelines. Part 5. Communications. IEC 1131-3 is the international standard for programmable controller programming languages. As such, it specifies the syntax, semantics and display for the following suite of PLC programming languages: •. Ladder diagram (LD). •. Sequential function Charts (SFC). •. Function Block Diagram (FBD). •. Structured Text (ST). •. Instruction List (IL). 33.

(45) Chapter 3 – Correlates Works and Component Quality, Evaluation and Certification One of the primary benefits of the standard is that it allows multiple languages to be used within the same programmable controller. This allows the program developer to select the language best suited to each particular task.. 3.1.2. RTCA DO 178B. A special committee (SC-145) of the Radio Technical Commission for Aeronautics (RTCA) convened in 1980 to establish guidelines for developing airborne systems. The report “Software Considerations in Air-borne Systems and Equipment Certification” was published in January 1982 as the RTCA Document Order (DO)-178 (and revised as DO-178A in 1985). Table 3.3: DO-178B DO-178B Certification Requirements All items are not required at all certification levels. DO-178B Documents:. DO-178B Records:. Plan for Software Aspects of Certification (PSAC). Software Verification Results (SVR). Software Development Plan (SDP). Problem Reports. Software Verification Plan (SVP). Software Configuration Management Records. Software Configuration Management Plan (SCMP). Software Quality Assurance Records. Software Quality Assurance Plan (SQAP) Software Requirements Standards (SRS) Software Design Standards (SDS) Software Code Standards (SCS) Software Requirements Data (SRD) Software Design Description (SDD) Software Verification Cases and Procedures (SVCP) Software Life Cycle Environment Configuration Index (SECI) Software Configuration Index (SCI) Software Accomplishment Summary (SAS). Due to rapid advances in technology, the RTCA established a new committee (SC-167) in 1989 with the objective of updating the DO-178A by focusing on five areas: documentation integration and production, system issues, software development, software verification, and software configuration. 34.

Referências

Documentos relacionados

Já que o método B&B pede para resolver o problema original como um problema linear relaxado, a alternativa mais comum para realizar isso é utilizar os métodos simplex e

O DIRETOR GERAL PRÓ TEMPORE DO Campus PARAGOMINAS DO INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO PARÁ – IFPA, nomeado pela Portaria nº 366/2015/REITORIA

Little reuse and agility, high costs.. Even

• “…Se puder verificar equipes incompletas no início da próxima aula seria uma mão

To control scope, we need to manage a list of tasks... To control time, we need to manage

O plano de trabalho não deve exceder oito (08) páginas, além daquelas do texto introdutório. O plano não poderá conter nenhuma outra forma de identificação do candidato, sob

A contribuigao dos pais ou responsavel e uma arma secreta no sentido de se chegar a finalidade proposta pela medida, que e a de evitar que se repita a pratica de um ato

Sendo o modelo tradicional de grade de programação ainda responsável pela organização dos programas de TV e, portanto, compreendido como o dispositivo por excelência da