-More and more functions in automotive systems are to components (i.e., Electronic Control Units (ECUs) of a enabled and controlled by software that is distributed over a large vehicle). This challenge is further aggravated by the fact that number of systems and components. In addition, the systems are modern vehicles consist of numerous systems and components. fmuonrcetioannsd. Cmroeraetiinngtearncodnmneacitnetdaitnoinigmaplhemigehn-ltevthele odveesrivreiedwvoehfitchlee As a result, the size of a document that contains a high-level relations between vehicle functions, systems, and components in a architectural overview of functions, systems, and components complete and consistent way requires a lot of effort. On the other has reached an enormous extent. As the number of systems in hand, such a high-level architecture is beneficial for planning modern vehicles continues to grow [6], so does the number of the development, analyzing the architecture, or defining product dependencies and thus also the required effort to maintain them wvaarsiamnatsn.uIanllythcisrepaatepdert,owdeocaunmaleynzteaall rveeahli-cwleorfludncdtoiocnusm, esnysttethmast, properly. In practice, such documents are oftentimes created and components of one car series and relations between these. and maintained manually in general-purpose tools such as MS We formalized the content of this model by providing a model Excel. of the concepts and a set of consistency rules. By evaluating On the other hand, a high-level overview of functions, the consistency rules on the given document, we found 213 systems, components, and their relations is essential to plan rceosnutlrtasd,iwcteorcyonrecllautdioentshaantdm5a4n7umalliyssimngairnetlaaitnioinngs. sBuacshedhiognh-tlheevseel development activities [7], to define product variants, or to architectures is highly error-prone and should thus be supported assess and optimize the systems' architecture [8]. This is by automation and appropriate tooling. especially important when components and sometimes even Index Terms-Traceability, Trace Link Recovery, Automotive whole systems are developed by (oftentimes multiple different) System Architecture Analysis suppliers [2], [9]. But the trace links not only facilitate the identification of dependencies, they are also needed even I. INTRODUCTION aside from organizational issues. The existence of trace links Innovation in the automotive industry is still primarily is mandated by regulations for safety-critical systems (see driven by functions that are implemented in software [1], ISO26262 [10]) and process improvement standards (see [2]. Since automotive systems encompass a wide variety of Automotive SPICE [11]) of the automotive industry. different domains (e.g., infotainment or control engineering In this paper, we analyze a high-level architecture document of mechanical and electronic components) which at the same of a vehicle series from practice. We aim at two things: time are highly-connected, it is a challenging task to maintain First, we analyze the underlying structure of the document to an overview of all the dependencies of the involved systems. define a model that represents its concepts (functions, systems, Studies have shown that developers are unaware of a large components, and relations between them). In addition, we fraction of these dependencies [3]. The concept of relating define a set of consistency rules. Based on the consistency entities that exhibit dependencies or other forms of connections rules, we are able to uncover missing connections and to is called traceability [4] and has been considered an important correct contradictory connections. Second, we apply the set of factor in the design of complex software systems (as in rules to the document to find out how many false and missing automotive software engineering) for quite some time [5]. Such connections are existent. connections are implemented by the use of trace links [4]. These The remainder of this paper is organized as follows. The trace links may appear in different directions, for example, next section provides details on the background. We explain horizontally (from system to system) as well as vertically what information the document contains, how the document (from system to function). Moreover, these dependencies also is composed, and how trace links are realized. The third occur across multiple dimensions (e.g., a system may rely section presents the underlying structure of the document on the output of another system's function). This means, one and introduces a set of rules that aim to ensure correctness system may depend on the function provided by another system. and completeness of the connections. In the fourth section, But keeping such an overview in a correct, consistent, and we present the results of applying the set of rules to the complete state involves even more aspects. One must also document and emphasize a number of situations that occur most keep track how all the systems and their functions are mapped frequently. The fifth section provides insights into related work
in the area of trace link recovery. The last section concludes this work and gives an outlook on future work.
As stated in the introduction, the relations between vehicle functions, systems, and components is often manually maintained in a high-level architecture document. The main content of this document is displayed in a table-like manner. Fig. 1 shows an abstract excerpt of this document.
It contains information on: names of systems in a vehicle series names of functions and the system they are associated with names of subfunctions and by which functions they are used information on whether functions and subfunctions are provided by or contribute to a system a mapping of systems, functions, and subfunctions to components
The first column in the table in Fig. 1 defines the type of an entity in the table1. It may be a system, a function, or a subfunction. The second column System assigns a system to each entity to indicate its membership. If the entity is a function, the third column specifies its name. The fourth column does the same for subfunctions. Function and subfunction entries of a system may reference a function or subfunction that is provided by that system or by another system. In the latter case, the other system must contain a corresponding entry for that function. To indicate this difference, the column Type specifies whether a function or subfunction is an own function of the system (denoted by the o in the appropriate cell) or an external function (denoted by the e in the appropriate cell). In case a function is an external function, the columns Provided By and Provided To give information which system provides the function and which system is using it. This information is redundantly provided for both the origin (e.g., F_2 in system S_n) and for the target (e.g. F_2 in system S_1). A function may be provided for multiple systems, while it only has one origin. In the example in Fig. 1, function F_2 from system S_n is used as a subfunction in function F_1 of system S_1. The rest of the columns represent the components of the vehicle series. An x in a cell maps an entity to a component, which means that the entry is deployed on the component. It has to be noted that subfunctions might intentionally not have a mapping to a component and functions might not have any subfunctions.
The whole document is managed in a commonly used spreadsheet program. Although the possibility exists, the spreadsheet does not make use of macros or other programmable routines. It is managed in a complete manual manner.
1The indentation does not exist in the original document and is used to improve clarity on which entity belongs to which entity
The rows in the document contain three types of references to other entities:
Vertical Traceability: Systems consist of functions, which themselves may consist of subfunctions (vertical traceability). This belongs to-relation is expressed redundantly in the document in two ways. First, a function belongs to a system if it is listed in a row below the system entity but before another system. The same applies for the relation of subfunctions to functions. This results in a hierarchical decomposition. Second, the column System contains the name of the system to which the function or subfunction belongs to.
Horizontal Traceability: Systems may use functionality provided by functions of other systems. Such a function or subfunction is denoted as an external function in the column Type. The relation between systems (horizontal traceability) is expressed using the columns Provided By and Provided To. For the affected function (or subfunction), these columns contain the name of the origin and the target respectively. This information is stored both for the system using the function and for the system providing the function. The providing system lists all of the systems using the function in the column Provided To. Similar to what is explained in (1), external functions also appear in a row below the system using it. As a result, this relation is also expressed redundantly.
Deployment Traceability: Systems, functions, and subfunctions are mapped to components to express that they are deployed on these. This is expressed by an x in the column of the respective component column. If a subfunction is deployed on a component, the function it belongs to and its system must also have a relation to this component (i.e., the deployment relations are aggregated).
To give an overview over the size of such a high-level architecture document, we provide some figures for the analyzed document. The document consists of 3,214 rows and 208 columns. It contains the basic architectural information for 169 systems and encompasses a mapping to 180 individual components. For the systems, 2,111 functions and 935 subfunctions are listed. Functions may be used multiple times by other systems as functions or as subfunctions. Both numbers include such multiple appearances.
The objective of our research effort was to gain insights in the practical realization of traceability in an automotive architecture document. The provided document was analyzed manually by the first author of this paper and peculiarities were discussed with the contributing authors of this paper. This has lead to the identification of a number of problems concerning the existing traceability information in the document. Based on these findings a set of rules was created to automatically improve the completeness and consistency of the traceability in the document. This set of rules is presented in a conceptual manner in the next section. The rules were then formalized and System
Function implemented. This way we were able to gather information on what kind of problems appear how frequently. The results of this analysis are explained and discussed in Section IV.
The underlying structure of the document as explained in the previous section is visualized in Fig. 2. The boxes represent the three entities System, Function, and Component. The arrows display the connections between them. For our approach, we distinguish between two different kinds of connections: 1) Connections that are existing explicitly in the document (represented by dotted lines) 2) Connections that we can derive from the existing relations (represented by dashed lines)
For the connections represented by enumeration item 1) we aim to improve the completeness by finding missing connections and adding these to the document. The connections represented by enumeration item 2) only exist implicitly in the document. For these dependencies, it is necessary to follow other existing (explicit) connections to make them visible. For instance, to find dependencies between systems, it is necessary to follow an external function of a system back to its originating system. Although such connections are not yet documented explicitly in the document, developers of the OEM mentioned that these connections would provide valuable information to them. Hence, we also intent to find these connections.
Besides, we also attempt to find and correct inconsistent and incorrect connections. Incorrect and inconsistent connections are characterized by missing information about the origin or target of the trace link. E.g., a function is provided to a certain system, but that system does not contain the function.
Overall, we want to improve the quality of the traceability links in the document based on the extracted structure. We try to achieve this goal by proposing a set of rules that find missing links and correct false links.
The rules we propose can be categorized into two sets.
The first set (consisting of 8 rules) aims to identify and repair incorrect links (correcting rules) while the second set (consisting of 18 rules) aims to recover missing trace links (recovering rules). The second set of rules addresses both kinds of connections in the document as mentioned in the enumeration in the previous subsection. A number of such cases where links are either missing or incorrectly implemented as well as a solution are depicted in the Fig. 3 to Fig. 8. Besides, a short description and the number of rules for both sets is displayed in TABLE I. Entity Type System Function Type Provided By Provided To System S_1 Function S_1 F_1 e S_2 S_1 System S_2 Function S_2 F_2 o System S_3 Function S_3 F_3 o
(a) existing Entity Type System Function Subfunction C_1 C_2 System S_1 x Function S_1 F_1 x Subfunction S_1 SF_1 x
Subfunction S_1 SF_2 x …
Hence, Fig. 10 depicts the dependency of a function F_1 to a function F_3, resulting from a dependency of F_1 to F_2 which in turn depends on F_3.
Fig. 11 depicts a dependency of a function F_1 to a component C_1. This dependency results from a subfunction (Fig. 11a) or another function (Fig. 11b) which has a dependency to component C_1 and is used by the function F_1.
Fig. 12 depicts the dependencies of a system S_1 to another D. Recovering Rules system S_2 that results from a function F_1 using the output
The rules for recovering missing connections are created by of a function F_2 of system S_2. transitively deducting connections from existing connections. Fig. 13 is similar to the situation displayed in Fig. 11a but These rules create trace links between functions, systems, propagates the dependencies further up to the system. and components. The main intention of these rules is to These rules only showcase a part of all possible rules. The make connections explicit. Examples for such connections are total number of 18 rules were systematically gathered by going displayed in Fig. 10, Fig. 11, Fig. 12, and Fig. 13. The thicker through all possible combinations of connections that might arrows between the entities symbolize existing connections. exist and assessing them towards their necessity in practice. The narrow arrows are the connections that are created by our That also includes recursive structures that appear when, for approach. instance, multiple functions are involved (as in Fig. 10). The next section presents the results from applying the rules to the described data set.
In this section we present the results of applying the rules to the described data set. The process of the evaluation started with the implementation of the approach and its rules. This implementation was then used on the already described data set. In this we regard the number of trace links before the application of the rules, after the application of the correction rules (first rule set) and after the application of the recovering rules (second rule set). These numbers are also visualized in Fig. 14. The objective of the evaluation was to find out how often certain faulty situations occur. We chose certain deficiencies because, in our view, these reflected the ones with the biggest impact on the document quality. This left us with a total of four question we aimed to answered. Moreover, we wanted to know how many trace links existed before and after the application of our approach and how many corrections were made. Hence, the question we wanted to answer are the following:
Q1) How many external functions are found that were not defined? We describe an external function as not defined if the function does not exist in the system that is supposed to be the originating system. Hence, we look for an external function which is not listed in the specified originating system. This situation is also displayed Fig. 3.
Q2) How many components are connected to a function but not to the system of the function? The circumstances reflected by this question are the same as displayed in Fig. 13 and Fig. 6.
Q3) How many components are connected to a system but not to any function of the system? In the context of this question, we look for the number of components which are connected to systems but not to any of the functions of the system (also displayed in Fig. 7). Such a situation indicates that there is no existing rationale for the dependency between the system and the specified component.
Q4) How many components are connected to subfunctions but not to the function using the subfunction? This question is similar to Q3. But instead of functions and systems, it aims at subfunctions and functions (also displayed in Fig. 8).
Q5) How many trace links exist before the application of the approach and how many exist after the application of the approach? With this question we aim to find out how many trace links existed before and after the application of our approach.
Q6) How many changes were made by the correcting rules? By answering this question, we try to find out how many mistakes could be automatically fixed by our approach.
After the application of the approach, we analyzed the results to answer the previously stated questions. Fig. 14 visualizes the answers of the questions. Considering question Q1), the approach recovered 95 external functions which did not exist in the specified originating system. It is possible that such a situation arises then a function, which is used by another function or system does not exists anymore, or an external function is needed by the considered system and another system is responsible for this functionality. So the function also has to be created in the corresponding system. Between components and systems 160 trace links were recovered (Q2)). Considering question Q3), we identified 129 cases in which components are connected to systems for no reason. Similarly for Q4), we identified 52 missing trace links between components and functions. To answer question Q5): the analysis shows 5,564 initially existing connections. After the application of the first set of rules 7,308 connections exists. This number of (a) functions as source (b) systems as source connections results from filling in the Provided By column for each function. After the application of the approach 7,855 connections exist. Hence, the method recovered 2,291 implicit existing trace links. These trace links consists of trace links, which exists through filling Provided By and Provided To columns, and trace links recovered by the application of the second set of rules. For the last question Q6) we found that the correcting rules were applied 213 times.
In this subsection we discuss whether the links added by our rules provide additional benefit. For this purpose, we compare how many trace links existed before the application of our approach and how many after. We do this for both trace links from functions and from systems.
The results for functions are displayed in Fig. 15a and for systems in Fig. 15b. For functions initially 432 trace links existed. Our approach was able of recovering 61 more trace links. Hence, we were able to improve the trace link coverage for functions by about 12%.
For systems initially 810 trace links existed. Here, we found 486 additional trace links that did not exist before. This represents 37% of all trace links that should have existed.
In more detail, we observed that 11 out of 18 recovering rules are relevant for the examined document. We derive this conclusion from the fact that these rules recover trace links that already existed in many places between entities. The remaining 7 of the 18 rules could not create any trace links because the corresponding structures did not appear in the document. Hence, these 7 rules are more of a theoretical nature.
All in all, our results confirm related findings that
maintaining traceability requires a significant effort for even moderately
sized systems [
Automatically complementing trace links between or within
software engineering artifacts falls into the area of trace link
recovery [
Text-based information retrieval approaches (e.g. [
The method presented in this paper makes use of the structure
of the artifacts and is usable at any time. Unlike the mentioned
and other related approaches, it is independent of textual
information (which as a source of ambiguity, cannot achieve
full reliability [
In this paper, we presented an analysis of trace links in a high-level architecture document of an automotive OEM. We extracted the underlying structure of the document and derived a set of rules that ensures the correctness and completeness of trace links. The rules, we proposed, were implemented in order to improve the quality of the document. An evaluation of this method shows that 547 missing trace links were created and 213 incorrect or inconsistent trace links were corrected.
In future, it may prove to be fruitful to implement such rules in the program the document is maintained. This may encourage a better quality from the start and prevent occurrences of defects and inconsistencies whenever it is manually edited. But we think, it would even be more promising to use modeling tools instead of a spreadsheet program to represent such information. Although it remains doubtful whether this can be accomplished in industrial practice on a wide scale. Future work should also address the impact on other developments artifacts that are derived of the document analyzed in this paper. More generally, it needs to be assessed how the rules can be adapted to documents other than the one investigated in this work.