Ranking Software Components Using a Modified ...

Ranking Software Components Using a Modified PageRank Algorithm Including Safety Aspects Dominik Reinhardt Software-Architecture and Platform Software BMW Group, Munich, Germany Email: [email protected] Abstract—Automotive software is increasing rapidly in its size, amount or complexity and the demand for calculation power rises. According ISO26262, additional non-functional requirements for safety-relevant applications must be considered. Therefore, analyzing software networks is necessary to identify problems within an early development state. For future multicore systems, complex software structures probably impede a safe segregation of software components between cores. In this paper, we want to use social network measurement methods to analyze automotive software architectures. Here, the interconnection of single software components and their influence within the network is focused. We use a modification of Google’s PageRank algorithm, where websites partly inherit the rank of their interlinked neighboring websites, and transfer these techniques to automotive needs. For our evaluation, we use data structures of an exemplary electronic control unit of BMW.

I.

I NTRODUCTION

Today’s cars are fully equipped with several high featured Electric and Electronic (E/E) systems, integrating complex software components. Over time, we have witnessed a continuous increase in the number of passenger protection systems. As a result, the computation effort for advanced driver assistance systems will rise in the future [1], [2]. Additionally, resources, such as computing power, are bounded by several walls [3]. Functional safety for E/E systems within passenger cars make it necessary to reconsider former software integration strategies. The ISO26262 [4] demands freedom from interference for safety-relevant hard- and software components within Electronic Control Units (ECUs). To stand against that problem, semiconductor manufacturers already deliver compliant hardware controllers with several safety supporting features. From a software engineering perspective, the entire isolation of safety-relevant software parts from the remaining system can relax expensive safety qualification processes. Multicore technology can be a possible solution for decoupling tight woven software spatially (memory protection) and temporally (different cores). In automotive multicore systems these components will use a comprehensive basic software and share several common components. However, high frequent inter-core communication should be prevented within realtime systems. Graph-based approaches to relate additional information about future multicore software mappings were already discussed in [5], [6]. The challenge nowadays is to deal with such new requirements in the automotive sector This work was funded within the project ARAMiS by the German Federal Ministry for Education and Research with the funding IDs 01IS11035. The responsibility for the content remains with the authors.

and integrate them continuously into multicore systems during ECU development processes [7], [8]. Software components within automotive E/E embedded systems can be highly interconnected with each other. Some software components are more important than others, as they can serve as a service for several applications and they can either deliver information for components integrated within an ECU, or offer additional internal platform functionalities. More or less, each software component is connected directly or indirectly to every other software component within the car. On an architectural level, non-functional requirements like functional safety must be considered as well. To be prepared for software relocation between cores within a multicore system, existing embedded software components should be loosely coupled to each other. In 1967, the American psychologist Stanley Milgram stated in [9] and [10] that every person is connected to everyone else all over the world in a chain of rounded 6 persons. It is called the Small World Phenomenon or The Six Degrees of Separation. The theory can be transferred to different environments and problems, such as throughput measurements for computer network to find relationships within social networks, even within online platforms. Such techniques are basically used to find the more or less important connecting components within a networked environment. Within social networks, the nodes centrality can be a measurement of how close a person is related to others [11]. Thus, the centrality of nodes represents the relative importance of each node connected by several edges within a directed graph [12], [13], [14]. Linton Freeman speaks about node betweenness in [15] and paraphrases point centrality as the potential for activity in communication. To explain this assumption, he describes the persons, who are highly interconnected within a social network as major channel of information. To improve the modularization of applications, Parnas early discussed in [16] how to decompose a software system. Similarly, the authors of [17] postulate that the functional cohesion of software components should be as high as possible. In [18], the authors propose behavioral metrics and use cluster algorithms to partition software systems into close related groups of software components. Similar to this approach, problems and suggestions to realize an efficient software mapping on hardware components are listed within [19]. Here, static analysis on an early transaction level based executable model by defining a set of metrics is suggested to get that mapping information. A close related approach to our method was suggested in [20], [21]. By using a graph based approach, the

authors want to find frequently used parts of a software system. With it, they want to improve the reusability of software parts within big business software systems. A similar approach for embedded automotive software systems is proposed in [22]. In this paper, we want to transfer these approaches of information retrieval to automotive E/E systems. Our goal is to use established methods for social network analysis to gain an impression of the relations between software units. The definition of software components is not limited to any specific architecture artifact or components granularity within this paper. For our analysis, the centrality of software components is expressed by their importance, which is influenced by interconnected applications. We suggest to analyze the influence of single software components within an ECU cluster. For that purpose, we developed a ranking mechanism to order embedded software components according to their communication behavior within an ECU cluster. As old applications are not developed for multicore operations [7], [23], automotive software can be difficult to be relocated or clustered between cores. These components are strongly connected to each other and probably require higher computational efforts for inter-core communication or synchronization needs. Therefore, we want to detect communication-intensive hotspots, and homogenize our software architecture. Furthermore, we will take into account safety-relevant software, where additional importance is individually added to each software unit. High centralized or coupled automotive software components with additional safety requirements could inherit their Automotive Safety Integrity Level (ASIL) from several connected components, which were not safety-relevant before and produce higher costs for software qualification [4]. The results could help to detect these software design risks in an early development state. Additionally, it enables software architects to continuously monitor such communication shortages and be prepared for software distribution within multicore platforms. The next sections are organized as follows: Section II gives a brief introduction to the PageRank and the TrustRank algorithms. Section III introduces our algorithm for ranking software components including safety aspects and gives an abstract example of its usage. In section IV, we evaluate our method by using a close-to-production automotive software component network with an exemplary parameter setting. The results and further applications of the evaluation are discussed within section V. Finally, section VI concludes the paper. II.

M ETHODS

Relationships within large scaled networks (e.g., social networks and the World Wide Web) change faster than servers can compute and always result in outdated nodes centrality. Automotive software networks, in contrast, are fixed at integration time and component relationships do not change at random. Based on the quality of data status, the influence and importance of single software components can be precisely determined. Therefore, we will use given network measurement methods (such as the PageRank Citation algorithm, [24], [25]) in a modified way, so to use them for analysis of embedded automotive software call-graphs.

A. PageRank Citation The PageRank Citation algorithm is a possible method to determine the centrality of each automotive application. It was first announced in [24] followed by [25] from Larry Page and Sergey Brin, founders of Google Incorporation. It is a well-known technique to rank the importance of websites within the World Wide Web, by referencing to each other, according to their backlinks. It is similar to the HypertextInduced Topic Selection (HITS) algorithm, which was developed by Jon Kleinberg [26] and ranks websites with a similar technique [27]. Beside PageRank and HITS, there are many other measurement techniques, such as Betweenness-, Degreeand Closeness centrality [15], [11]. The PageRank algorithm is based on an eigenvector problem [25]. It will determine the relative importance of a website compared to all other sites. The rank of a website is based on its predecessors (parent nodes). Their importance will fade to them (damped by α) and summarized individually. Because it is a recursive algorithm and the rank is calculated per site, many iterations are needed for convergence to get an accurate ranking. We now present the PageRank algorithm in detail. We consider N nodes with ranks Ri , i = 1, . . . , N , with N ∈ N. If a node j, with j ∈ {1, . . . , N }, is a predecessor of i, it is denoted by j → i. The number of out-links of a node j is called out-degree deg − (j). The normalized PageRank Citation algorithm for the rank Ri is: X Rj 1−α Ri = α + , (1) − (j) deg N j→i where α ∈ [0, 1] is a given parameter, e.g. 0.85, which acts as a damping factor. The equivalent matrix equation is: ~ = αM R ~ + 1 − α ~1, R N

(2)

where ~1 = (1, . . . , 1)T ∈ RN represents a vector with all elements equal to 1. Further, the transition matrix M is defined as  1 if j → i, deg − (j) (3) Mi,j = 0 else. B. TrustRank Algorithm For search engines, it is difficult to differ between really important sites and sites, which are only highly interconnected within the internet to increase their page rank. To tackle that problem, an alternative rank, the so called TrustRank, is suggested in [28]. Here, websites are ranked to be trustworthy or not. The inverse PageRank equation results in the desirability ranking for websites to act as a seed site. These are the most important sites, which spread out their trust to many other websites within the network. In the best case, these nodes point to others, which are equally or better ranked than themselves. For the inverse PageRank, the rank of node i potentially acts as a seed. It is defined as X Rj 1−α Ri = α + , (4) + (j) deg N i→j

where the number of in-links of a node j is defined by its indegree deg + (j). The equivalent matrix equation is:

components reference to it, connected through the backlinks of the component (see (1) and (3)).

~ = αM fR ~ + 1 − α ~1, R N f and the transition matrix M is defined by  1 if i → j, deg + (j) f Mi,j = 0 else.

Some components exhibit an intensive link behavior to several components in forward direction. Therefore, we calculate ranks from a backlink oriented approach, with a transposed matrix M T . In contrast to the PageRank, a component is important if it references to other important components with its front links. This process is very similar to the determination of seeds within the TrustRank algorithm (see (4), (5) and (8)), but SwcRank’s inverse transition matrix is not stochastic.

(5)

(6)

The rank of nodes, which are both trusted and seed sites, is ~ The remaining stored in the corresponding component of d. components are set to 0. Afterward, d~ is normalized to 1. Now, a similar step to (1) is calculated. It represents a biased version of not normalized PageRank, which sum up to 1, as well. The TrustRank algorithm for Ri is written as X Rj Ri = α + (1 − α)di , (7) deg − (j) j→i where di is the trust score of node i. The equivalent matrix equation is: ~ ~ = αM R ~ + (1 − α)d, R (8) where d = (d1 , . . . , dN )T ∈ RN and the transition Matrix M is equal to the PageRank Matrix in (3). III.

S OFTWARE C OMPONENT R ANK

We want to identify the relative importance of software components interconnected within automotive ECUs. Therefore, we developed the Software Component Rank (SwcRank), which is a modification of the Page- and the TrustRank algorithms. It is applied to a directed graph of interconnected automotive software units. The atomicity or modularity of software components should not be fixed within that stage. Software components are adoptable as logical containers expressed as nodes within a graph. Connections can be directed or undirected. Every value within the adjacency matrix is nonnegative. Anyhow, several components exist with no input or output relation. In few cases, the graph is strongly connected. This means that directed paths exist between each pair of components. A. Ranking Automotive Software Components Correlations of embedded software within a real-time system are typically not stochastic. Therefore, we start with adjacency matrices with only 0 and 1 entries, such that a rank is not split up among the neighbors of a node. Our approach results in a non-normalized rank vector, which represents the main difference respect to PageRank and its left stochastic matrix. Nevertheless, we can normalize our result at the end of each iteration. This ensures convergence because ranks cannot gradually increase in each iteration. It results in a stochastic matrix where the degree of static relations between nodes have no influence on rank distribution. This step is similar to the authority calculation within the HITS algorithm [26]. We want to clarify the algorithmic term structure, to find possible hotspots within the network. For a backlink oriented approach of software component ranking, we concentrate on rank scores, which flow from parents to children. Similar to the PageRank, a component will be important if other important

We consider N software components with the ranks Ri , where i ∈ {1, . . . , N }. The SwcRank in matrix-vector form is: ~ = αAR ~ + (1 − α) ~1. R N

(9)

Backlink oriented approach: Ranks are calculated by analyzing the backlinks of nodes. Here, another software component j will call component i, or simply transfer information data to it. The transition matrix is set to A = M , where  1 if j → i, Mi,j = (10) 0 else. Frontlink oriented approach: For the second calculation variation, which is similar to inverse PageRank of TrustRank [28], the outdegree of nodes will be analyzed. The rank depends on the components’ frontlinks. Here, the component i will call another software component j, or simply transfer information data to it. The transposed matrix A = M T (option 2) is defined as  1 if i → j, T Mi,j = (11) 0 else. Iterative solution: For both approaches, (9) is solved ~ 0 denote a given, arbitrary chosen start vector. iteratively. Let R In the k th iteration step, we compute ~ (k−1) + (1 − α) ~1, ~r(k) = αAR N 1 (k) (k) ~ R = (k) ~r , k~r k1

(12) (13)

where k~r(k) k1 denotes the `1 -norm. After each rank computa~ (k) has always tion cycle, the rank is normalized. The vector R a norm of 1, where k ≥ 1. Finally, there are two individual results for SwcRank calculation: the result of the frontlink oriented method and the result of the backlink oriented method. The resulting ranks can be analyzed separately, to identify in particular components, which intensively get or give lots of information to others. Both methods pursue a different point of view and deliver independent results from each other. If a final statement or resulting number is wished to measure nodes centrality, we suggest to summarize the both resulting values of frontlink and backlink-oriented approach to a condensed ranking value. To look at real embedded architectures, software components, in any kind of granularity, will have a more or less

intensive communication behavior. Some of them, will have more incoming information paths and collect data (fan-in). Some others will intensively transfer data to their neighbors (fan-out). According to this imbalance, we recommend to combine the results of front- and backlink approach for SwcRank calculation. Thus, every type of communication behavior is considered within a final result evaluation.

3 1

2

6

4 5

Fig. 1.

Software Component Rank example.

B. Complexity and Convergence TABLE I.

The adjacency matrix of connected software components is sparse, as each node is only linked to a small number of other nodes [27]. Similary to PageRank, the complexity of the SwcRank is O(K ∗ N ), i.e. it depends linearly on the total number of nodes N and on the number of iterations K. The final SwcRank vector, which solves (9) is computed iteratively. The computation can be stopped if the convergence is sufficient, i.e. if the difference between the current rank and the former iteration is small. Therefore, we introduce the stop criterion . The computation will stop if (k)

~ |R i

(k−1)

~ −R i

|≤

(14)

C OMPARISON OF RANK MEASUREMENTS .

Node-ID

PageRank

SwcRank

Backlink approach

Frontlink approach

1

0.046

2

0.208

0.208

0

0.208

0.466

0.238

3

0.228

0.222

0.398

0.225

0.173

4

0.234

0.373

0.190

0.183

5

0.145

0.381

0.173

0.208

6

0.145

0.173

0.173

0

of (10) and (11) shall be used separately for front- and backlink analysis.

~ i , with i ∈ {1, ..., N }, within the is TRUE for each node R k-th computed iteration cycle.

The main novelty of our algorithm is the use of fixed safety ~ Each element implementing technical ranks, included in d. safety requirements will inherit the highest postulated ASIL.

C. Ranking Safety-Relevant Applications

Let σA < σB < σC < σD be weights according to the ASILs A, B, C and D, as proposed in [4]. Like approved in the TrustRank algorithm, we will introduce the categorization according to [4] between different ASILs TA , TB , TC and TD , where, for example, TA is the set of nodes assigned to ASIL A.

Passenger safety is an important non-functional requirement for car manufacturers. E/E systems must protect safetyrelevant applications and their data from manipulation or other influences. According to [4], failures can occur spatially, temporally, and within information exchange. If information is transmitted from a sender to a receiver, data could be manipulated, causing hardware interferences. The AUTOSAR standard [29] specifies several protection mechanisms (e.g. memory, timing and end-to-end protection) to guarantee freedom from interference. In SwcRank, safety-relevant software applications should be ranked as well and are more important than others. Similarly to the Alpha-Centrality [13], TrustRank [28] or even the personalized PageRank [25], we will use a biased form of PageRank. This results in the normalized SwcRank algorithm: the rank for the i-th component is set to X Ri = α Rj + (1 − α)di , (15) j→i

with a given α ∈ [0, 1], which is a global design parameter of the algorithm. It controls the speed of convergence of the algorithm and the distribution of software components ranks within the network. From a practical point of view, if there are event-triggered relations within the call-graph, 1 − α can deal as a probability for acyclic calls. The vector d~ = (d1 , . . . , dN ) in (15) contains additional weights for safety-relevant nodes. ~ The equivalent Below, we propose a possible choice for d. matrix equation is: ~ ~ = αM R ~ + (1 − α)d, R

(16)

where the transition matrix M has to be replaced by M T in case of frontlink analysis. The appropriate transition matrices

We define for i ∈ {1, . . . , N }  σA if i ∈ TA ,     σB if i ∈ TB , σC if i ∈ TC , di =   σ  D if i ∈ TD ,  0 else.

(17)

~ = αM R ~ has a nonIn case d~ = ~0, the equation R ~ if and only if 1/α is an eigenvalue of M . trivial solution R It is unlikely to choose exactly a proper eigenvalue of M . Therefore, it is important, that d~ is assigned with any vector, which has at least one non-zero component. Otherwise the linear system of equations is homogenous and converges to the trivial solution (all results are 0). An example of SwcRank is depicted in figure 1. It represents a directed graph of six nodes, where node 2 is assigned by an additional ASIL. We choose α = 0, 85 and d~ = {0, 0.5, 0, 0, 0, 0} for parametrization. As start vector, we ~ 0 = ~1. The color intensity of figure 1 represents the choose R propagation of node importance within the graph. Because of the additional weight of node 2, the rank is higher than its neighbors. Table I shows the calculated results of figure 1, compared with the PageRank algorithm. The rank of node 2 propagates to the neighboring components. Nodes 2-5 build a cycle and ranks stronger propagate between this components. Node 1 inherits

importance from node 2, from a frontlink oriented approach, where components gain importance if they are pointing to important nodes. Along the way to node 6, the rank is already damped. Since node 1 has no backlinks and node 6 has no frontlinks, their corresponding rank is zero (column 4 and 5). D. Weighted Relations Between Software Components Despite single relations between software components, they can be connected several times with each other. Furthermore, the frequency of information transfer within a time frame is different for each connection. Therefore, we enrich connections between software components with additional weights. For backlink analysis, let Ni,j be the number of connecl tions pointing from j to i and let ωi,j be the weight of the l-th connection, l = 1, ..., Ni,j . The entries of the transition matrix M are set to Mi,j =

 PNi,j l=1

0

l ωi,j

if j → i, else.

(18)

The definition of M T is straight forward; instead of backlinks we consider frontlinks and sum up the weights assigned to the outgoing edges of a node. For our work, we use the following three levels of granularity to weight edges. Either there is a sender or receiver of any information or a functionality, which calls another one. 1) 2) 3)

Relations between software components represent the basic interaction behavior. The multiplicity of connections between two components. The frequency, meaning how often components will interact over a single connection.

Based on an AUTOSAR Top-Level Architecture description, we will achieve the first and second information level, which are required within the standard. The third topic must be introduced externally by given timing measurements. Safetyrelevant components must still be tagged manually. IV.

R ESULTS

We want to analyze software components and their communication behavior within a safety-relevant environment. Typically, there is information flow between software components, which is either called cyclically or sporadically. Several interconnected components build networks of communication chains. The effect of such chains can be visualized by a graph to find proper hotspots, where some components are called more often than others. The data we used is based on a transformed directed callgraph, given by an exemplary ECU project of BMW. The control unit serves as an integration platform for several automotive applications [23], [30]. This example poses a typical software structure including highly interconnected software components, which are partly safety-relevant. We notice that symmetric graphs with undirected connections, the forward and backward computation results for SwcRank are identical. Figure 2 shows the TopLevelComposition of our ECU, which implements the connections of

our application software. Every node, which is marked black, represents an AUTOSAR software component. Safety-relevant components are marked red with a cross. We imported over 150 components, which are connected by over 1000 assembly connectors. It is worth to mention that some multiple edges between components occur in the example presented by figure 2. These represent n:m communication relations between two software components. We have not added specific weights to given transitions, as they are typically not mentioned within an AUTOSAR TopLevelComposition. For that purpose, a deeper technical information level for our database is needed. For our example, we choose safety-relevant software components assigned by ASIL B. They represent safety-supporting mechanisms and are responsible to respond redundant signals or evaluate calculated results with different methods. These components and their functionality must be proven according to given technical safety concepts, to achieve former identified safety goals. To guarantee freedom from interference, the temporal, spatial and information exchange protection is important for these components. In our case safety-relevant components should provide a reliable source of information for several customer functions. To limit safety qualification efforts, these data paths should have as less dependencies to non-safetyrelevant components as possible. Such software components must be separated from other non-trusted software components [4]. This is reasonable as freedom from interference between software components must be guaranteed. If this does not happen, former non-safety-relevant software components could inherit the dependent safety level. Such components must be considered within the safety evaluation process as well [4]. For the rank calculation pictured in figure 2, further parameters must be pre-allocated. We set α = 0.85 as recommended in [25]. The biased safety distribution is represented by d~ and prioritizes individual components. For our tests, we chose to set the values of ASILs linearly, where σA = 0.25, σB = 0.5, σC = 0.75 and σD = 1. All other components are set to ~ 0 = ~1. As stop criterion di = 0. As start vector, we choose R we choose  = 1e−6. Within our example, convergence is achieved after thirteen iterations. This is fast and for us an efficient measuring method. Several parameters can influence the convergence. If α is approximately 1, ranks will be distributed more extensively and additional iterations are needed for convergence. Choosing a smaller value will result in a more restrictive rank inheritance and the resulting vector will converge faster. This factor has a powerful influence on smoothing component ranks within the graph. If safety-relevant applications should have more impact onto the calculation, α and d~ must be scaled up correspondingly. We denote, by simply watching at a big scaled graph, the centrality of nodes can hardly be determined. If there are too many components to analyze, the better way to distinguish ranks is by looking at the resulting numeral values. Figure 3 shows the distribution of ranks. The majority of nodes has a rank smaller than 0.02 with a peak observed at 0.0033. Safety-relevant software components are distributed around the rank of 0.02. There are a few single hot spots with a larger rank between 0.04 and 0.07. Thus, there are only a few software components, which are highly interconnected.

component, freedom from interference must be also proven. If that is not possible, they are separated from the remaining software components. Therefore, these nodes are typically smaller within our example, because their connections to others were strictly avoided. V.

D ISCUSSION

We showed that measurement techniques from social network analysis can be transferred to embedded automotive software networks. We suppose that software networks are growing in the future and are getting more and more unmanageable. Within Large Scale Software Integration [23] scenarios, where many software components are integrated onto a single hardware platform, delivered by several different suppliers, this paradigm is getting more complicated. Therefore, techniques to analyze these meshed software structures are needed to sustain the specified system operation purpose and avoid unexpected behavior.

Fig. 2.

Results view of Software Component Rank.

Number of Components

35

Non-safety-relevant Safety-relevant

30 25 20 15 10 5 0 0

Fig. 3.

0.01

0.02

0.03 0.04 0.05 0.06 Rank of Components

0.07

0.08

Distribution of the Software Component Rank.

The most distinctive nodes within figure 2 are service components of the basic software. For example, the Diagnostic Event Manager (DEM), used to trace Diagnostic Trouble Codes (DTCs), is one of these. Diagnostic functionality is used from several components. Such software is uniquely integrated for each ECU. Depending on the communication behavior of connected components, much information is transferred between them within a small time frame. Several application software components use polling strategies and call others components many times within a time frame. To achieve separation between components, safety-relevant mechanisms are less connected to other components. Therefore, unnecessary program complexity and wide spread dependencies among each other should be avoided. According to the chosen α, the rank has more or less influence and flows out of the node. If they are connected to a basic software

Within our algorithm, components which possess a high centrality value are more important than others. Based on their relationships, these components have more influence on other components. This happens, for example, when there is a deeper functional dependency (e.g. in data or control flow) to connected components. This would be an important information for safety-relevant applications as fault propagation in high interconnected networks must be avoided [4]. Here, every data path must be checked to guarantee freedom from interference. The scope of SwcRank is not restricted to direct neighbors of a safety-relevant node. In particular, it considers the importance and centrality of nodes within an interconnected chain of components. In a condensed way, the communication and calling intensity can be visualized by a graph. This is scalable to bigger software networks, as well. It highlights communication hot spots within the system and should enable concepts for separation between safety-relevant and non-safety-relevant components. We would expect to have homogenized centrality values during the chain of interconnected components. If side effects like cross linked components occur, these structures can be analyzed in an early development state. For multicore systems, components with high centrality are probably difficult to share between cores. Due to system optimization purposes, probably software components must be relocated to gain spatial or temporal independence or to balance load between cores. Then, inter-core communication is used to have access to applications from other cores and transfer information between relocated software. Measured by the frequency of transferred information, software components will be called more intensively. This will cause more traffic and CPU utilization if software is dedicated to a fixed core and is called from components located on other cores. At this point, software segregation and partitioning between cores is not efficient. Summarized, if the centrality of neighboring components is high, it is a trade-off if such applications should be integrated on different calculation cores. To avoid inter-core communication overheads, such components should be located together on the same core. It is hard to optimize the system architecture if such hotspots exist and the methodology to distribute these central applications between calculation cores is complex.

Because many components are executed only at system start-up and do not produce constant processor load, SwcRank differs between cyclic and sporadic calls. Even if there are several relations between each others, which only represent ’who communicates to whom’, these components will not cause higher CPU load due to communication effort. Connections between such components are weighted to a minimum. We suggest trying to avoid single hotspots and construct a homogenized network, where all nodes exhibit a similar centrality value. If this is not the case, it means that the complexity of such components is too high or there is the need for stronger decoupling of components to gain a better system modularity [16]. AUTOSAR describes the internal behavior of software components, with respect to the RTE. Anyhow, the standard does not actually dictate to describe its internal execution semantics of source code. Our graph does not cover any causal relationships and is based on correlations between components. For our analysis and methods, the functional dependencies between software components and their existing relations are sufficient. If there is an intensive data exchange, we expect, that the component itself will compute and transfer this information to neighboring components in a similar interval. Due to this subjective point of view, every node’s centrality propagates in a damped way through the network. We do not only count the in- and out-directed edges, or only multiply them by their information transfer rate, see (18). Every relationship, either cyclically or sporadically, has more or less influence to connected components. Other algorithms like PageRank use a stochastic approach, where centrality is inherited according to their amount of a node’s in- or outdegree, see (3) and (6). Our weight is mapped on each edge directly, which matches better to embedded software, as the calling frequency can differ for each connection. In our opinion, a component’s rank should not be split by the amount of data paths and inherited evenly from its neighbors. Nevertheless, we will normalize our calculation after each iteration to gain comparable results, see (12) and (13). If this does not happen, convergence could not be guaranteed. It is possible to weight edges with a special attribute like the calling frequency of components in advance. This knowledge can result in already existing experience or further runtime analysis and measurements. However, it is difficult to mix more attributes at once, which is a limitation of the SwcRank. To get more precise results for future analysis, we need to enrich our model with more information of finer granularity. A possible solution is to analyze AUTOSAR description files (ARXML) of single software components. Here, we can determine more information about the intensity of interconnections from single software components. Software dependencies and channels, including their communication direction, can be extracted in detail. Additional attributes, which enrich the given AUTOSAR description language with further properties (e.g. detailed timing information [31]), could help to refine the provided data base. Concerning the amount of transitions between software components, it is worth to gather further knowledge about the integrated task cycles and how often software components or software parts are executed within a time frame.

Our goal was to bring order to automotive ECUs. SwcRank serves as a first forecast for software architects at the beginning of development. We use a similar approach like PageRank or other measurement methods to determine centrality within a (social) network. In fact, the introduced algorithm brings a relative order to software components networks already on a logical architecture level. We saw that only a few automotive components are highly interconnected with each other. Google, instead, is ranking billions of interconnected websites and performs a huge matrix-vector multiplication. We did not change the basic behavior of the PageRank algorithm. Therefore, our method is scalable to bigger graphs or networks of any kind. Within this paper we focused on a small graph for presentation reasons. Furthermore, it is possible to rank even smaller interconnected units like C-functions or expand the call-graph over several ECUs. To continue our studies of interconnected software component centrality, in the next step, the SwcRank should be proved on a more detailed level, which stronger relates to real hardware. In this step, more technical information like the demand of hardware resources or measurements for processor load will already exist. Additionally, several software mechanisms for partitioning are elaborated and restrict our model. To extend our research, a method to build cliques of ranked software components should be determined to allow a more efficient software partitioning. As suggested in [20], [21], the authors cluster nodes or application parts according to their similarity. For us, analyzing the communication behavior between software components as proposed in [18], [19] could be an indicator to group close related software components together within a composition. VI.

C ONCLUSION

Automotive software components are highly interconnected with each other. Some components are more ’in the middle of things’ than others. We showed that well established techniques for social network analysis can be a way to bring a relative order to an E/E system, already on logical architecture level. It is necessary to analyze the communication structure and frequency of software components before starting to write any line of source code. Within this paper, we presented an algorithm to measure the relative importance of components within automotive software networks according to their communication flow and possible safety-relevance. With it, we can determine stronger and weaker relations between software components and derive a statement of the software modularity. We note that, the SwcRank is not fixed to any granularity of software components. Depending on the input parameters, it is further usable for software containers and even for C-functions (like AUTOSAR Runnables). R EFERENCES [1]

M. Broy, “Challenges in Automotive Software Engineering,” in Proc. ACM 28th International Conference on Software Engineering (ICSE 2006), Shanghai, China, May 2006, pp. 33–42. [2] S. F¨urst, “Challenges in the design of automotive software,” in Design, Automation Test in Europe Conference Exhibition (DATE), 2010, Mar. 2010, pp. 256 –258. [3] H. Sutter, “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software,” Dr. Dobb’s Journal, vol. 30, no. 3, pp. 202–210, 2005.

[4] [5]

[6]

[7]

[8]

[9] [10]

[11]

[12] [13]

[14] [15] [16] [17] [18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

ISO 26262, “Road vehicles - Functional safety - Part 1-10,” International Organization for Standardization, 2011. J. Bengtsson and B. Svensson, “Manycore performance analysis using timed configuration graphs,” in Systems, Architectures, Modeling, and Simulation, 2009. SAMOS ’09. International Symposium on, Jul. 2009, pp. 108–117. G. Buttazzo, E. Bini, and Y. Wu, “Partitioning Real-Time Applications Over Multicore Reservations,” Industrial Informatics, IEEE Transactions on, vol. 7, no. 2, pp. 302–315, May 2011. W. Schwitzer, R. Schneider, D. Reinhardt, and G. Hofstetter, “Tackling the Complexity of Timing-relevant Deployment Decisions in Multicore-based Embedded Automotive Software Systems,” SAE International Journal of Passenger Cars - Electronic and Electrical Systems, vol. 6, no. 2, pp. 478–488, Apr. 2013. J. Schneider, M. Bohn, and R. R¨oßger, “Migration of Automotive Real-Time Software to Multicore Systems: First Steps towards an Automated Solution,” in Proceedings Work-In-Progress Session of the 22th Euromicro Conference on Real-Time Systems, ser. ECRTS’10, Jul. 2010, pp. 37–40. S. Milgram, “The small world problem,” Psychology Today, vol. 1, no. 1, pp. 61–67, 1967. J. Travers, S. Milgram, J. Travers, and S. Milgram, “An experimental study of the small world problem,” Sociometry, vol. 32, pp. 425–443, 1969. S. Wasserman and K. Faust, Social Network Analysis: Methods and Applications, ser. Structural Analysis in the Social Sciences. Cambridge University Press, 1994. P. Bonacich, “Power and centrality: A family of measures,” American Journal of Sociology, vol. 92, no. 5, pp. 1170–1182, 1987. P. Bonacich and P. Lloyd, “Eigenvector-like measures of centrality for asymmetric relations,” Social Networks, vol. 23, no. 3, pp. 191–201, Jul. 2001. P. Bonacich, “Some unique properties of eigenvector centrality,” Social Networks, vol. 29, no. 4, pp. 555–564, Oct. 2007. L. Freeman, “A Set of Measures of Centrality Based on Betweenness,” Sociometry, vol. 40, pp. 35–41, 1977. D. L. Parnas, “On the criteria to be used in decomposing systems into modules,” Commun. ACM, vol. 15, no. 12, pp. 1053–1058, Dec. 1972. W. P. Stevens, G. J. Myers, and L. Constantine, “Structured design,” IBM Systems Journal, vol. 13, no. 2, pp. 115–139, 1974. F. Vahid and D. Gajski, “Closeness metrics for system-level functional partitioning,” in Design Automation Conference, 1995, with EUROVHDL, Proceedings EURO-DAC ’95., European, Sep. 1995, pp. 328–333. G. Agosta, F. Bruschi, and D. Sciuto, “Static Analysis of TransactionLevel Communication Models,” Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, vol. 27, no. 8, pp. 1412– 1424, Aug. 2008. K. Inoue, R. Yokomori, H. Fujiwara, T. Yamamoto, M. Matsushita, and S. Kusumoto, “Component rank: relative significance rank for software component search,” in Proceedings of the 25th International Conference on Software Engineering, ser. ICSE ’03. Washington, DC, USA: IEEE Computer Society, 2003, pp. 14–24. K. Inoue, R. Yokomori, T. Yamamoto, M. Matsushita, and S. Kusumoto, “Ranking significance of software components based on use relations,” Software Engineering, IEEE Transactions on, vol. 31, no. 3, pp. 213–225, 2005. M. Hobelsberger, “Reusability evaluation of component-based embedded automative software systems,” Ph.D. dissertation, University of Magdeburg, 2012. D. Reinhardt and M. Kucera, “Domain Controlled Architecture - A New Approach for Large Scale Software Integrated Automotive Systems,” in International Conference on Pervasive and Embedded Computing and Communication Systems (PECCS 2013), Feb. 2013, pp. 221 – 226. S. Brin and L. Page, “The anatomy of a large-scale hypertextual web search engine,” in Seventh International World-Wide Web Conference (WWW 1998), 1998. L. Page, S. Brin, R. Motwani, and T. Winograd, “The PageRank Citation Ranking: Bringing Order to the Web,” Stanford InfoLab,

[26] [27]

[28]

[29] [30]

[31]

Technical Report 1999-66, Nov. 1999, previous number = SIDL-WP1999-0120. J. M. Kleinberg, “Authoritative sources in a hyperlinked environment,” Journal of the ACM, vol. 46, no. 5, pp. 604–632, 1999. A. N. Langville and C. D. Meyer, Google’s PageRank and Beyond: The Science of Search Engine Rankings. Princeton, NJ: Princeton University Press, 2006. Z. Gyongyi, H. Garcia-Molina, and J. Pedersen, “Combating Web Spam with TrustRank,” Stanford InfoLab, Technical Report 2004-17, Mar. 2004. AUTOSAR Administration, “AUTomotive Open System ARchitecture,” http://www.autosar.org, 2014. D. Reinhardt, D. Kaule, and M. Kucera, “Achieving a Scalable E/EArchitecture using AUTOSAR and Virtualization,” SAE International Journal of Passenger Cars - Electronic and Electrical Systems, vol. 6, no. 2, pp. 489–497, Apr. 2013. AUTOSAR, “Specification of Timing Extensions,” Mar. 2014, version 4.1.0 – Final.