A Requirements Specification Template of A Communication Network Based On CAN Protocol To Automotive Embedded Systems
A Requirements Specification Template of A Communication Network Based On CAN Protocol To Automotive Embedded Systems
A Requirements Specification Template of A Communication Network Based On CAN Protocol To Automotive Embedded Systems
October 2010
A Requirements Specification Template of a Communication Network Based on CAN Protocol to Automotive Embedded Systems
Dario Almudi Neto Faculty of Exact and Natural Sciences Universidade Metodista de Piracicaba (UNIMEP) Piracicaba So Paulo Brazil e-mail: netoneto@globo.com and Luiz Eduardo Galvo Martins Faculty of Exact and Natural Sciences Universidade Metodista de Piracicaba (UNIMEP) Piracicaba So Paulo Brazil e-mail: martinsleg@hotmail.com ABSTRACT This paper presents the results of studies that made possible to propose a particular contribution to improve the quality on developing automotive embedded systems through a requirements specification template of a communication network based on CAN protocol. The whole template structure is composed by sections that specify the controlling units, the subnetworks, the data dictionary and the general aspects of the communication network. A study case was performed to test the proposed template and a study of the requirements of an embedded automotive environment was specified. The conclusions of this study and the evaluation are presented and further studies are suggested. This template can be used by engineers and designers with industrial or scientific purposes. Keywords: Communication Requirements, Embedded Automotive Systems, Template Specifications, CAN Net, Requirements Engineering 1. INTRODUCTION The automotive embedded systems have a meaningful role in the industrial automotive sector and many technological laboratories around the world work on developing several resources. The result of these researches innovate the automotive sector through the application of new technologies in the design of vehicles. The current systems of vehicular automation involve mechanical and electronical devices and computational systems, and due to their complexity, they stimulate the introduction of new design methodologies. An important issue is that the development methodologies require a high level of abstraction for design, verification and validation of the proposed system. Some weaknesses are diagnosed in the context of automotive embedded systems in the current scenario and some of these processes can be identified in the context of automotive embedded systems. Processes that enable the organization of necessities to develop automotive embedded systems are scarce, and the specifications of the design of automotive embedded systems are often supplied by automakers which keep their planning and documentation in a confidential basis. Companies, and some research sectors, attempting the development of their automotive applications, whatever their commercial purpose or not, perform their work without a requirement specification document suitable for embedded systems. Another important aspect to be considered in the development of automotive embedded systems scenario is the wide variety of existing communication protocols, allowing a wide field for alternatives of communication network design. The CAN (Controller Area Network) communication protocol has been used in the development of embedded automotive design, and consequently has lead the companies that strongly invest on solutions to be used on the manufacturing of a vehicle to provide CAN as a part of their products. This wide variety of communication protocols available and their operating criteria and specifications turn the requirements specification for automotive embedded systems into a standard commercial challenge. Based on the presented scenario, the aim of this paper is to present a template for requirements specification of a communication network based on CAN protocol for automotive embedded systems. The methodology for the development of the template began with the study of the data communication network of automotive embedded systems, seeking to understand its operation and specifically focusing CAN as a communication protocol. The elicitation processes and the analysis were performed based on technical documents and on standards related to the researched context. Volere [1] and IEEE Std 830-1998 [2] were also studied with the purpose of acknowledging the specification documents of existing requirements and they helped clarify how a template can be structured. A template validation was performed through its usage in a study case to prove its applicability. Results and final considerations are discussed and presented. This paper is organized as follows: section 2 presents the aspects of Requirements Engineering that work as a basis to assess the needs to structure a template. Section 3 presents an explanation on the CAN communication network, which is the basis for the development of this template. Finally section 4 presents the template and its applicability in a study case and also presents a discussion of the results obtained from the evaluation performed. 2. REQUIREMENTS ENGINEERING Sommerville [3] defines Requirements Engineering (RE) as a process created to cover all the activities involved in discovery (production), documentation and maintenance of a set of requirements for a computer based system.
143
October 2010
Figure 1 Spiral Model for the Requirements Engineering Process [6]. Figure 1 presents a spiral model for the Requirements Engineering process based on the elicitation, analysis, specification and validation of the requirements activities. Kotonya and Sommerville [6] propose a model of iterative and incremental process just like the approach in the spiral model for the software development, which includes the necessary feedback to the characterization of the requirements dynamic nature. According to Taurion [7], to develop embedded systems it is necessary to adopt methodologies starting with a high level of abstraction as well as the use of tools that automate the most all the stages of the methodology. Requirements Elicitation To Belgamo and Martins [8], despite requirements elicitation is the first step in Requirements Engineering, it doesnt happen only once, for requirements elicitation is an iterative process where all the other phases may contain extractions and requirements analysis that may happen whenever the analyst thinks it is necessary. The information gathered during the requirements elicitation must often be interpreted, analyzed, modeled and validated before the engineer starts feeling confident that the set of requirements was obtained. Therefore, the elicitation techniques are closely related to other RE activities mostly the elicitation technique used is motivated by the choice of modeling and vice versa: many modeling involve the use of certain types of elicitation techniques [9]. Requirements Analysis At this phase the clients and users necessities are analyzed to get the definition of the software requirements. The goal is to detect imperfection, omissions and redundancies in order to discover the necessary and desired software requirements. Inconsistency, duplicity of information, ambiguity, conflicting requirements are also examples of problems that can be found out in this phase of the process. The commitment and participation of the stakeholders is crucial in this phase.
Requirements Specification To organize the requirements of the system, the results obtained from the elicitation and the analysis will be then documented through texts, diagrams, models or rules of prototyping. This process has a high level of difficulty and heavily relies on the engineer writing skills. Among the benefits obtained by the generated documents, it is possible to cite [4]: a) The specification document is the basic communication vehicle between developers and users on what has to be built; b) The specification document register the results of the analysis of the problem (obtained through elicitation and requirements analysis); c) The specification document defines the properties the system must have along with its restrictions imposed to the design and implementation; d) The specification document is the basis for cost and schedule rates; e) The specification document is the basis for developing the system test plan; f) The specification document provides a behavior standard definition expected by the professionals involved in the system maintenance; g) The specification document is used to register changes in the system engineering. Validation Requirements validation is concerned with showing that the requirements actually define what system the customer wants [3]. According to Martins [4] the main problems found during the requirements validation are: Not meeting the standards of quality; Requirements poorly described; which lead to ambiguity; Errors in modeling the problem or system; Conflicting requirements not identified during the analysis phase. This step is also concerned in finding problems in the requirements. However the processes (analysis and validation) are different. Validation concerns are related to the development of a complete draft for the requirements document, while analysis involves working with incomplete requirements [3]. 3. CAN (CONTROLLER AREA NETWORK) The data transmission systems in the industry began in a quite simple way, using connection like serial RS-232 and RS-485 protocols. However, industries started developing more complex systems, with their own technologies, protocols, software and hardware better fitted to their necessities. CAN is an internationally standardized serial bus system providing functionality of data link layers of OSI/ISO reference model. In 1983, Bosch Company had started its work of development of a data network automobiles, thus resulting in CAN protocol. The company has improved the use of this protocol to other industrial applications such as: medical systems, navigational instrumentation, elevators control systems, textile production, general production control systems [10]. A CAN network is usually characterized as a network that, despite having been conceived for embedded systems, has working groups in the automation area that envision the systems suitability to be used as an industrial local
144
October 2010
a) Embedded Environment Definition The environment of an automotive embedded system may have different purposes. It is possible to establish an environment featuring the control of certain functions, or define an environment to provide diagnosis of situations occurring inside the environment or even more common, to implement these two functionalities inside the automotive embedded system, developing a simultaneous controlling and diagnosis structure. The items that detail the environment definition are (see Figure 3): Purpose of application: The embedded environment could be defined as control application, diagnosis or control and diagnosis. Type of Architecture: The distributed architecture is characterized by the presence of several intelligent modules throughout the application, each one receiving only part of the data, usually those generated close to them, and sending them to the modules that require such information to their own processing. The choice between distributed or centralized architecture will be done according to the necessity and size of the project. The centralized architecture is composed by only one controlling unit and there is not the necessity of a bus communication since it is slightly performed with only sensors and actuators. If the choice is a centralized architecture, the use of CAMA template is not necessary. Logical Domains: Performing division into the vehicles logical domains provides an overview on the interrelated structures that formally describe an integrated system. Examples of logical domains: Propulsion System, Vehicles Motion, Body and Interior, Electric System, Multimedia, etc. This item requires the data of all logical domains specified in the environment. Environment Protection System: The protection systems on embedded environment are performed by fuses in charge of protecting the electric harness of electronic components attached to it. Two elements have to be defined in this item: The maximum current of the circuit (MCC) and the fuse value (FV) to be used as a protection. Number of ECUs: The Electronic Control Unit (ECU), also known as controlling unity or controlling module is an electronic device that controls one or more electrical systems in a vehicle. Some modern vehicles have up to 80 ECUs. This item requires the data of the number of ECUs independently of the type of established attachment, even if among ECUs the communication is performed by a protocol other than CAN. This item has to specify the total number of ECUs presents in the bus. Number of Subnetworks: Subnetwork is the segment that establishes the communication between a set of ECUs in a different way on the bus. Each subnetwork must have the detailed specifications of communication on defined files. This item specifies the amount of subnetwork presents on the total bus of the automotive embedded enviroment. Total Size of the harness: This item specifies the total size of the data bus harness of the environment, adding the harness segments of all subnetworks.
145
October 2010
or may not be protected. It specifies the voltage of the outputs and if they are protected or not (WP with protection / NP no protection). ECU Terminal: Defines if this ECU will be terminal carrier (120 Ohms resistors) inside the bus. Additional Function. Gateway: resource which primary purpose is to interconnect distinct networks in a manageable way with the possibility of separating colliding domains and interpreting different protocols. Bridge: used to interconnect networks, allowing free access between them. Repeater: it is an equipment used to interconnect identical networks, since they electrically amplify and regenerate transmitted signals in the physical environment. Routers: equipment used to create forwarding routes of data packages in different networks. See rule SAE J1939 for an understanding on each of the detailed applications. Notes: Specification and additional information on ECU. Other technical details about the ECU can be showed. Due to the wide variety of manufacturers in the market, one suggestion is to specify the source of the ECU, in order to make easier its identification.
Notes: Additional information about automotive embedded environment. Aspects of the environment that can assist the understanding or special features of the design could be approached.
Figure 3 Card of Environment Definition b) ECU Definition Electronic Control Units are the main components of the automotive embedded system. Through them the points of input and output of information are set, since they are in charge of processing it. ECUs may or may not contain a CAN transceptor attached to its structure and when it doesnt happen, this resource must be installed in the ECU so that the communication with the CAN bus occurs. The items to be specified about ECUs are presented below (the specification card is presented in Figure 4). ECU Identifier: A numeric or mnemonic label that identifies the ECU in an unique way inside the automotive embedded system environment. Type of ECU: It identifies the electronic module according to its application. Acronyms are used to identify the electronic modules: BCM body controlling module, BAM back area module, TCM transmission controlling module. These are only some examples to illustrate this feature.
Figure 4 ECU Card Type of CAN Controller: Relating to transmission and reception buffers. BasicCAN low cost controller with simple capacity of filtering acceptance. FullCAN controller that handles the most complex messages through dual-port RAM, freeing CPU to manage just a few bits. Quantity of inputs: Number of input the ECU has, determining which are digital and which are analog. Type of Input: These can be digital or analog. Digital inputs capture information in two states 0 or 1, and can be translated by states of voltage (0 and 5 Volts or 0 or 12 Volts). They may or may not be supervised (in case of being supervised the input must be connected to an analog gate of the ECU and have a resistor connected in parallel). Analog inputs are able to capture information that varies infinitely between two values, 0 or 5 Volts and 0 or 12 Volts. This is the item to specify the voltage of the input and when they are digital, if they are supervised or not (WS with supervision / NS no supervision). Quantity of output: the number of outputs the ECU has, determining which are digital and which are analog. Type of Output: Outputs can be digital or analog. Digital outputs are divided into two groups: Low Side Driver (LSD) e High Side Driver (HSD). Both may c) Subnetwork Definition Subnetworks are formed by part of the bus to which two or more ECUs are attached. The established characteristics inside the subnetworks are standardized to allow that the ECUs linked to this subnetwork bus to communicate. The information on the subnetworks is transmitted through fixed format frames with different but limited lengths. When the bus is idle, any connected node can start transmitting a new frame. If two or more nodes start transmitting frames simultaneously, the conflict of accessing to the bus must be solved by arbitration through the contention identifier. The arbitration mechanism must ensure that there are not waste of information neither time. The transmitter with the highest priority frame will have access to the bus. The items that detail the subnetwork definition are (see Figure 5): Subnetwork Identifier: A numeric or mnemonic label that identifies the subnetwork in a unique way inside the automotive embedded system environment. Type of Subnetwork: Specifications of the subnetwork that are attached to the ECU. Example: CAN network, LIN network, SDI network, etc. Operating voltage: Specifies which operating voltage will power the bus. The values must be determined to VCAN_H, VCAN_L, zero dominant logic level (Vdiff)
146
October 2010
Figure 6 Field of Arbitration Card e) Structure for Data Dictionary Definition Specifications to be presented in the template are: Message ID: A numeric or mnemonic label that identifies the message format in an unique way inside the automotive embedded system environment. Message name: A label that helps identifying the purpose of the message. Field of Arbitration ID: A numeric or mnemonic label identical to that found in the card of the Field of Arbitration. Size of Message: Size in bytes of message according to what was established in the field of controlling. Data Bytes: Data bytes specification that must be performed in binary or hexadecimal format to compose the message. ECU TX ID: A numeric or mnemonic label identical to that found in the ECU card. It identifies the ECU that transmits the message. ECU RX ID: A numeric or mnemonic label identical to that found in the ECU card. Ii identifies the ECU that receives the message.
Figure 5 Card of Subnetwork Structure for Defining the Field Arbitration Specifications to be presented in the template are: d) of
Message ID: A numeric or mnemonic label that identifies the message in a unique way inside the automotive embedded system environment. This ID must be specified in the file of the message. Field of Arbitration ID: A numeric or mnemonic label that identifies the field of arbitration in a unique way inside the automotive embedded system environment. This ID has to be the same specified in the file of the message. Message Format: It determines which will be the standard of the message: 11 bits for the standard format or 29 bits for the extended format. Bits specification: Bits will be specified according to the option of the message format. It can adopt the suggestion of the division in classes, categories and address of the node. Figure 7 Card of Data Dictionary f) Error Checking CAN has a very reliable error handling. The errors can be detected, whatever they are global or local. This possibility sets CAN as a high level security solution to be implemented in automotive embedded systems. There are five ways of handling errors that CAN enables: a) Bit Error: any transmitter continues monitoring the data bus while transmitting. If the monitored bit has a different value from the one sent, an error is flagged. b) Coding Error: it happens when the monitored bit had the same value six times. In the sixth occurrence the error is flagged.
147
October 2010
Practical use: checking how useful the template showed itself to the automotive embedded system designer, assessing whether the requirements specifications of the environment were well documented through the use of the template. Positive evidence related to the use of the Template
The template proved to be easy to use. The study case showed that all models of specification files could be used without any difficulties. The scope of the template proved to be sufficient, since there was not a record of non-relevant item in the template in the study case. The structure proposed for the template, dividing it into their respective specifications files, proved to be adequate because there was not a register of inconvenience or misunderstanding about the use of the proposed files. Negative evidence related to the use of the Template
Some aspects regarding to the standardization of terminology our units of measure interfered with the interpretation of requirements. It was observed that even if the automakers follow the rules established by SAE and ISO, they also create mechanisms to keep their commercial secret. The proposed template approached the CAN protocol more specifically due to its use be more intense in the embedded system environment. However, new technologies and commercial decisions can change this preference. Appraisers analysis
The CAMA Template was taken to three automotive embedded system engineers working in multinational companies with more than ten years of expertise. They were asked to issue their opinion on the template based on their daily basis professional activities. Figure 9 presents the results of the evaluation performed by the automotive engineers that participated in the analysis of the CAMA Template. The Likert Scale was used to check the level of organization, understanding, approach, documentation and use of the template. Figure 8 Physical Layout of the Embedded Environment Adopted in the Study Case The aim of this study case was to practice with the proposed template to specify the automotive embedded systems data communication requirements providing by this experience, a templates experimental evaluation. During the study case three characteristics of the template were aimed to be analyzed: Adequacy of coverage: checking if the technical variables reached in the template covered the main elements that constitute an automotive embedded systems environment; Easiness of use: checking whether the explanations provided for filling in forms as well as their layout were easy to understand and use;
Figure 9 Results of Evaluation by Engineers Some aspects discusses by the automotive engineers were: a) A positive highlight is related to the templates organization, which is very important for a better
148
October 2010
The study case provided a first trial on the proposed template. The initial experience has confirmed a promising perspective of application of the template, illustrating the usefulness and relevance of the proposal. It is clear that more experiments have to be conducted to confirm the efficiency and benefits of the template, as well as to point the necessary adjustments and adaptations in this requirements specification tool. As future works, it is intended to develop software to support the use of template and expand it to other communication protocols adopted by the automotive industry. 7. REFERENCES [1] J. Robertson, S. Robertson, Volere Modelo para Especificao de Requisitos. 14. ed. Verso em Portugus. London: [s.n.], ago. 2009. [2] IEEE Std 830-1998. Recommended Practice for Software Requirements Specifications. IEEE - Institute of Electrical and Eletronic Engineers. Inc., 1998. [3] I. Sommerville, Engenharia de Software. So Paulo: Addison Wesley, 2007. [4] L. E. G. Martins, Uma Metodologia de Elicitao de Requisitos de Software baseada na Teoria da Atividade. Tese de Doutorado. Campinas, SP: UNICAMP, 2001. [5] R. S. Pressman, Engenharia de Software. 6. ed. So Paulo: McGraw-Hill, 2006. [6] G. Kotonya, I. Sommerville, Requirements Engineering: Processes and Techniques. Chichester: John Wiley & Sons, 1998. [7] C. Taurion, Software Embarcado. A nova onda da Informtica. Rio de Janeiro: Brasport, 2005. [8] A. Belgamo, L. E. G Martins, Um Estudo Comparativo sobre as Tcnicas de Elicitao de Requisitos do Software. In: Congresso Brasileiro da Sociedade Brasileira de Computao, 20. Concurso de Trabalhos de Iniciao Cientfica, 19., 2000. Curitiba: PUCPR, 2000. p. 7-20. [9] J. Goguen, M. Jirotka, Requirements Engineering: Social and Technical Issues. Seattle: Academic Press, 1994. [10] Bosch, CAN Specification Version 2.0. Stuttgart: Robert Bosch GmbH, 1991. [11] A. A. GUIMARES, Eletrnica Embarcada Automotiva. So Paulo: rica, 2007. [12] M. Broy, Challenges in Automotive Software Engineering. 28th International Conference on Software Engineering (ICSE). China: Shanghai, 2006. Received: Aug. 2010. Accepted: Sept. 2010
149