Quang-Vinh Dang

Izabela Nielsen
email: izabela@m-tech.aau.dk

Kenn Steger-Jensen

Mathematical Formulation for Mobile Robot Scheduling Problem in a Manufacturing Cell

Keywords: Scheduling, Mobile Robot, MIP, Feeding Sequence

This paper deals with the problem of finding optimal feeding sequence in a manufacturing cell with feeders fed by a mobile robot with manipulation arm. The performance criterion is to minimize total traveling time of the robot in a given planning horizon. Besides, the robot has to be scheduled in order to keep production lines within the cell working without any shortage of parts fed from feeders. A mixed-integer programming (MIP) model is developed to find the optimal solution for the problem. In the MIP formulation, a method based on the (s, Q) inventory system is applied to define time windows for multiple-part feeding tasks. A case study is implemented at an impeller production line in a factory to demonstrate the result of the proposed MIP model.

Introduction

Production systems nowadays range from fully automated to strictly manual. While the former is very efficient in high volumes but less flexible, the latter is very flexible but less cost-efficient. Therefore, manufactures visualize the need for transformable production systems that combines the best of both worlds by using new assistive automation and mobile robots. With embedded batteries and manipulation arms, mobile robots are more flexible to perform certain tasks such as transporting and feeding materials, machine tending, pre-assembly or quality inspection at different workstations of production lines. These tasks have such relatively low level of complexity that mobile robots are able to take over. Besides, using mobile robots can lead to less energy usage or less tool-changing costs than commonly industrial robots attached to a fixed surface. These advantages pave the way for mobile robot to be implemented in the transformable production systems. Within the scope of this study, a given problem is particularly considered for a single mobile robot which will automate multiple-part feeding tasks by not only transporting but also collecting containers of parts and emptying them into the feeders needed. However, to utilize mobile robots in an efficient manner requires the ability to properly schedule these feeding tasks. Hence, it is important to plan in which sequence mobile robots process feeding operations so that they could effectively work while satisfying a number of technological constraints.

Robot scheduling problem which is NP-hard has attracted interest of researchers in recent decades. Dror and Stulman [START_REF] Dror | Optimizing Robot's Service Movement: a One Dimensional Case[END_REF] dealt with the problem of optimizing onedimensional robot's service movements. Crama and van de Klundert [START_REF] Crama | Cyclic Scheduling of Identical Parts in a Robotic Cell[END_REF] considered the flow shop problem with one transporting robot and one type of product to find shortest cyclic schedule for the robot. Afterwards, they demonstrated that the sequence of activities whose execution produces one part yields optimal production rates for three-machine robotic flow shops [START_REF] Crama | Cyclic Scheduling in 3-machine Robotic Flow Shops[END_REF]. Crame et al. [START_REF] Crama | Cyclic Scheduling in Robotic Flowshops[END_REF] also presented a survey of cyclic robotic scheduling problem along with their existing solution approaches. Kats and Levner [START_REF] Kats | Parametric Algorithms for 2-cyclic Robot Scheduling with Interval Processing Times[END_REF], [START_REF] Kats | A Faster Algorithm for 2-cyclic Robotic Scheduling with a Fixed Robot Route and Interval Processing Times[END_REF] considered m-machine production line processing identical parts served by a mobile robot to find the minimum cycle time for 2-cyclic schedules. Maimon et al. [START_REF] Maimon | A Neural Network Approach for a Robot Task Sequencing Problem[END_REF] introduced a neural network method for a material-handling robot task-sequencing problem. Suárez and Rosell [START_REF] Suárez | Feeding Sequence Selection in a Manufacturing Cell with Four Parallel Machines[END_REF] dealt with the particular real case of feeding sequence selection in a manufacturing cell consisting of four parallel identical machines. Several feeding strategies and simulation model were built to select the best sequence. Most of the work and theory foundation considered scheduling robots which are usually inflexible, move on prescribed path and repeatedly perform a limited sequence of activities. There is still lack of scheduling a free-ranging mobile robot which is able to move around within a manufacturing cell to process multiple-part feeding tasks consisting of collecting, transporting, and delivering containers of parts to feeders. The scheduling problem becomes interesting as the robot has been coordinated to manufacturing so that robot's services maintain production in the lines. Therefore, in this paper we focus on scheduling a single mobile robot for multiple-part feeding tasks whose time windows could be determined based on the inventory system (s, Q) as well as predefined maximum and minimum levels of parts in feeders.

The remainder of this paper is organized as follows: in the next section, problem statement is described while the mathematical model is formulated in Section 3. A case study is investigated to demonstrate the result of the proposed model in Section 4. Finally, conclusions are drawn in Section 5.

Problem Description

Fig. 1 below shows a typical layout of the manufacturing cell. In particular, the work is developed for a real cell that produces parts for the pump manufacturing industry at a factory in Denmark. The cell consists of a central storage known as a part supermarket, a single mobile robot, and several production lines including multiple machines which are fed by multiple feeders. An operator is responsible to put parts into small load carriers (SLCs) which are placed in the storage. The robot will retrieve and carry several SLCs containing parts from the storage, move to feeder locations, feed all parts inside each SLC to each feeder, then return to the storage to unload all empty SLCs and take filled SLCs. Because of the limitation on capacity, the feeders have to be served a number of times in order maintain production without any shortage of parts. The mobile robot thus has a set of feeding tasks to carry out during a given planning horizon.

Fig. 1. Layout of the manufacturing cell

To enable the construction of a multiple-part feeding schedule of the mobile robot, the following assumptions are made: an autonomous mobile robot is considered in disturbance free environment; the robot is able to carry one or several SCLs at a time; all tasks are periodic, independent, and assigned to the same robot; working time and traveling time of the robot between any locations, and consuming rates of parts in feeders are known; all feeders of machines have to be fed up to maximum levels and the robots starts from the storage at the initial stage. In order to accomplish all the movements with a smallest consumed amount of battery energy, the total traveling time of the robot is an important objective to be considered. Hence, it is important to determine in which way the robot should feed the feeders of machines in order to minimize its total traveling time within the manufacturing cell while preventing the production lines from stopping working.

Mathematical Formulation

In this study, a mix-integer programming (MIP) model is developed to determine an optimal route of the mobile robot visiting a number of locations to process multiplepart feeding tasks. The model is inspired by well-known traveling salesman problem [START_REF] Toth | The Vehicle Routing Problem[END_REF] and the (s, Q) inventory system [START_REF] Silver | Inventory Management and Production Planning and Scheduling[END_REF]. The latter is applied to define time windows for the feeding tasks. In practice, the MIP model can be applied to small-scale problems with a few numbers of feeders and short planning horizon. Under these scenarios, the MIP model is reasonably fast to give exact optimal solutions, which can be used as reference points to quantify the scale of benefits achieved by a meta-heuristic method further developed. Notations, time windows, and a formulation for the MIP model are extensively described in the following subsections.

3.1

Notations N : set of all tasks (N = {0, 1, 2, …, n} where 0: task at the storage) n i : number of times task i has to be executed R : set of all possible routes (R = {1, 2, …, R max } where 1 if robot travels from -th task location to -th task location in the route 0 otherwise

R max = Σ n i , ∀i ∈ N \{0}) e ik : k-th
jlr ik k i l j r x   
 y ik : route number to which k-th task i belongs s ik : k-th starting time of task i

Time Windows

Time windows of multiple-part feeding tasks of the mobile robot could be determined as shown in Equation ( 1), (2), and (3) below.

p i = (u i -v i )c i , ∀i ∈ N \{0} (1)
e ik+1 = e ik + p i , ∀i ∈ N \{0}, k = 1 ÷ n i ( 2
)
d ik = e ik + (v i -0)c i , ∀i ∈ N \{0}, k = 1 ÷ n i (3)
Task for feeder i whose periodic time is calculated as Equation ( 1) has a number of times/executions /    ii n T p to be performed. The release time of an execution of task i is set when the number of parts inside feeder i falls to a certain level v i (Equation (2)); while the due time of an execution of task i is defined when there are no parts in feeder i (Equation ( 3)).

Mixed-Integer Programming Model

Objective function:

11 min (4)

j i n n jlr ij ik i N k j N l r R tx       \{0}, 1 (5)
ik ik ik i e s d i N k n       1 01 \{0} 1 1 (6) j n jl j N l x    01 \{0} 1 1 (7) j n jlr j N l r R x       1 0 ( 8
) i n ikr ik i N k x r R      -1 , , 1 , 1 , , , (9)
jlr ik i j T rR x Z i j N k n l n i j Z Z Z              1 1 \{0}, 1 (10)
j n jlr ik i j N l r R x i N k n          1 1 \ {0}, 1 (11)
i n jlr ik j i N k r R x j N l n         1 \{0} 1 (12) j i n n jlr ik i N k j N l x Q r R               0 0 0 1 (13) , , 1 , 1 jlr jlr ik i ij ik ik jl ik i j ij jl r R r R ij s w t x L x y y t w t t s i j N k n l n                                1 \ {0}, 1 ( 14
) i n jlr jl ik j i N k r R y r x j N l n           , , 1 , 1 (15)
jlr jl ik ik i j rR y y x i j N k n l n            0,1 , , , 1 , 1 (16)
jlr ik i j x r R i j N k n l n          : positive integer variable , 1 ( 17
) ik y i N k n    
The objective function (4) minimizes the total traveling time of the robot. Constraint [START_REF] Kats | Parametric Algorithms for 2-cyclic Robot Scheduling with Interval Processing Times[END_REF] ensures that starting time of an execution of a task satisfies its time window. Constraints ( 6) and [START_REF] Maimon | A Neural Network Approach for a Robot Task Sequencing Problem[END_REF] indicate that the robot starts from the storage at the initial stage. Constraint [START_REF] Suárez | Feeding Sequence Selection in a Manufacturing Cell with Four Parallel Machines[END_REF] prevents the robot repeating an execution of a task. Constraint (9) eliminates the sub-tours among executions of tasks, where Z is a subset of Z T , where Z T is a set of all executions of tasks at feeders and the storage, and Φ denotes and empty set. Constraints [START_REF] Silver | Inventory Management and Production Planning and Scheduling[END_REF] and ( 11) force an execution of a task in one route to be done exactly one. Constraint (12) forbids the robot to feed more SLCs than the maximum number of SLCs Q it allows to carry. Constraint (13) handles the traveling time requirements between any pair of executions of tasks, where L is a given sufficiently large constant. In case two executions of the same task or different tasks are connected but they are not in the same route, the robot should visit the storage to unload empty SLCs and load filled ones. Constraint (14) assigns an execution of a task to a route and constraint (15) guarantees the ascending sequence of route numbers for executions of tasks. Constraints ( 16) and (17) imply the types of variables.

Case Study

To examine performance of the MIP model, a case study is investigated at the CR factory at Grundfos A/S. The chosen area for this case study is the CR 1-2-3 impeller production line which produces impellers for industrial pumps. The CR line consists of four feeders that have to be served by the mobile robot. These feeders are indexed from 1 to 4 and named Back Plate, Van Feeder 1, Van Feeder 2, and Front Plate respectively. Besides, different feeders are filled by kinds of parts, namely back plates for feeder 1, vanes for feeder 2 and 3, front plates for feeder 4. On the CR line, a number of vanes are welded together with back and front plates to produce an impeller. Fig. 2 below particularly illustrates the aforementioned production area where the proposed model has been implemented in the factory.

Fig. 2. CR 1-2-3 impeller production line

The maximum number of SLCs carried by the robot is 3. The average number of parts per SLC fed to feeder 1 or 4 is 125 (approximately 2 kg/SLC), while the average number of parts per SLC fed to feeder 2 or 3 is 1100 (approximately 1 kg/SLC). The maximum levels, minimum levels, consuming rates of parts, and working time of the robot are given in Table 1, while Table 2 shows traveling time of the robot from one location of a task to another (feeder 0 means the central storage). The case study has been investigated during approximately 50 minutes because of the limitation on robot batteries. The MIP model has been coded in the mathematical modeling language ILOG OPL 3.6. The problem of case study has been run on a PC having an Intel® Core i5 2.3 GHz processor and 4 GB RAM. The optimal solution obtained is given as: 0 -1 -4 -4 -0 -1 -1 -4 -0 -1 -2 -4 -0 -3 -0 , with total traveling time being 503 seconds which makes up 16.4 % of the total time. With 4040 decision variables, the computational time for this case using the proposed model is 4305 seconds. The detailed solution is shown in Table 3 and Fig. 3 below.

Conclusions

In this paper, a new problem of scheduling a single mobile robot for multiple-part feeding tasks in a manufacturing cell is studied. To accomplish all tasks within allowable limit of battery capacity, it is important for planners to determine optimal feeding sequence to minimize total traveling time of the mobile robot while considering specific features of the robot and a number of technological constraints. An MIP model is developed to find optimal solution for the problem. A particular real case of the impeller production line composing of four feeders is described to show result of the proposed model. The result was quite properly applied during practical feeding operations and it demonstrated that all feeders had no shortage of parts. For further research, the complexity of the problem will increase when considering a larger number of feeders and/or longer planning horizon. Hence, a meta-heuristic method will be taken into account for solving large-scale mobile robot scheduling problems. Besides, re-scheduling mechanisms based on obtained schedules and feedback from the shop floor will be developed to deal with real-time disturbances.

Fig. 3 .

 3 Fig. 3. Gantt chart for the optimal solution of the case study

  release time of task i d ik : k-th due time of task i p i : periodic time of task i w i : working time of robot at task i location t ij : traveling time of robot from task i location to task j location c i : consuming rate of parts in feeder at task i location v i : minimum level of parts in feeder at task i location u

i : maximum level of parts in feeder at task i location Q : maximum number of SLCs could be carried by robot T : planning horizon Decision variables:

Table 1 .

 1 Maximum, minimum levels, consuming rates, and working time of robot at feeders

	Feeder	0	1	2	3	4
	Maximum level (part)	-	250	2000	2000	250
	Minimum level (part)	-	125	900	900	125
	Consuming rate (s/part)	-	4.5	1.5	1.5	4.5
	Working time of robot (s)	90	42	42	42

Table 2 .

 2 Traveling time of robot from one location to another

	Traveling time (s)	0	1	2	3	4
	0	0	43	33	27	48
	1	46	0	29	30	53
	2	32	34	0	36	42
	3	29	26	35	0	40
	4	47	60	46	39	0

Table 3 .

 3 Detailed optimal solution of the case study

	Task	Feeder	Index of execution	Starting time	Route
	1	1	1	1030.0	1
	2	4	1	1125.0	1
	3	4	2	1375.5	1
	4	1	2	1687.5	2
	5	1	3	2155.0	2
	6	4	3	2250.0	2
	7	1	4	2549.0	3
	8	2	1	2620.0	3
	9	4	4	2704.0	3
	10	3	1	3000.0	4

Acknowledgments This work has partly been supported by the European Commission under grant agreement number FP7-260026-TAPAS.


Juan Li

Frédérique Biennier
email: frederique.biennier@insa-lyon.frcghedira@liris.cnrs.fr

Chirine Ghedira

An Agile Governance Method for Multi-tier Industrial Architecture

Keywords: Service-Oriented Industrial Governance, SOA, Lean Six Sigma

To fit the ever-changing business context, developing large scale networked and collaborative strategies involve increasing both enterprise and information system agility and interoperability. At the same time, lean and six sigma theories have also been used in industries to improve the industrial process itself so that profitability, quality and reputation are increased. In order to achieve these goals, an efficient and comprehensive governance method is necessary. However, mostly existing governance methods are isolated, they do not allow a dynamic composition of monitoring services, and they lack of a converging Business Process Management and Service Oriented Architecture as a holistic ecosystem. To overcome these limits, this paper propose an agile governance method for multi-tier industrial architecture, this architecture can couple the IT service principles with the Lean-6 sigma theories. This comprehensive governance architecture could eliminate monitoring blind spot lead to eliminate waste and defects.

Introduction

To fit the renewed globalised economical environment, enterprises have to develop new large scale networked and collaborative strategies, involve increasing both enterprise and information system agility and interoperability. This trend has been favored by the development of interoperable and rather agile IT technologies based on services leading to SOA-based information systems reorganization. At the same time, lean and six sigma theories have also been used in industries to improve the industrial process itself so that profitability, quality and reputation are increased. One of the key points of lean six sigma consists in monitoring each step of manufacturing process and business service information as well as avoiding blind spots for governance. However, most of the existing industrial services architecture governance methods are rather "fixed" and lack agility, overall perspective governance as they have unilateral perspective, just focused on the service level or IT vision. They do not support efficiently dynamic collaborative organization. As these isolated governance systems do not allow a dynamic composition of monitoring services and these service strategies lacks (by now) of an efficient governance system coupling the different layers of this complex ecosystem (including business strategies, business/industrial/IT services, execution platforms and infrastructure means).

To overcome this limit, we propose a multi-layer industrial service governance method, introducing the motivation and background (section 2). After, section 3 presents our multi-tier governance architecture's. Lastly, section 4 presents discussion and further works.

Background

In order to manage the increasing complexity of information technology systems and to deliver maximum real business value, Enterprise Architectures (EA) have been developed more than 20 years [START_REF] Lankhorst | Enterprise Architecture at Work -Modeling, Communication, and Analysis[END_REF]. An EA explains how all the information technology elements in an organizationsystems, processes, organizations, and peoplework together as a whole [START_REF] Morganwalp | Enterprise Architecture Measures of Effectiveness[END_REF]. Enterprise Architecture Framework (EAF) defines how to organize the structure and views associated with an EA [START_REF]Enterprise Architecture Framework[END_REF].

A well functioning EA Governance is necessary to achieve a successful IT organization. Appropriate governance methods enable IT to become a key differentiator in creating an agile, adoptable enterprise [START_REF]EA: A Governance Framework[END_REF].

Weill, P. and Ross, J. have presented that even some organizations have noticed the importance of EA Governance, most of the EA Governance methods separate the IT governance from business-performance metrics. There is still a big gap between business requirement and IT technology capacity, and it is difficult to make them understand each other [START_REF] Weill | MIT Sloan management review: a matrixed approach to designing IT governance[END_REF].

Consequently, with the evolution of technology and management, industrial organization commonly has three layers: business layer, service layer, IT infrastructure layer. Service layer is an abstract layer connects business layer and IT infrastructure layer. Service-Oriented Architecture (SOA) is becoming the architectural style of choice in many enterprises. One of SOA's greatest strengths is its enhanced flexibility of services. It enables agile business processes and loose couple with specific technology [START_REF]SOA Governance: revolutionizing business to meet customer demands[END_REF]. Figure 1 gives a high-level view of the various SOA layers [START_REF] Mitra | Business-driven development[END_REF]. High-level view of SOA layers (from Business-driven development IBM: http://www.ibm.com/developerworks/webservices/library/ws-bdd/) Due to the nature of SOA: demand for better business and IT alignment, the discipline of SOA governance has evolved. SOA governance defines the organizational structures and processes that are required to successfully adopt SOA, it helps minimize complications. SOA governance increases the connection among business processes, functional capabilities, organizational entities, end users, applications, and data. So SOA governance is a must if a company is to maintain and grow market share in a marketplace where customers expect and demand speed of delivery.

Numerous models for SOA Governance have been proposed so far. Michael N. and Julian E. et al. presented an approach for a generalized SOA Governance model. They identified six main components which form a mechanism for the optimal support of governance activities for an SOA system in a company. Nevertheless their SOA governance model, (as the most of SOA Governances) lack of ability to govern the IT infrastructure and ignore the infrastructure performance could impact the service performance [START_REF] Michael | Towards a Generic Governance Model for Service Oriented Architectures[END_REF]. Jan B. and Detlef S. outline a reference model for SOA governance that is based on the standardized SOA-RM [START_REF] Mackenzie | OASIS Reference Model for Service Oriented Architecture 1[END_REF] and motivated from aspects relevant to methodologies for SOA [START_REF] Detlef | A conceptual framework for the governance of service-oriented architectures[END_REF]. However, their model is conceptual and they did not propose approach to connect their model to common frameworks for IT governance and Enterprise Architecture. SOA Governance methods, cannot give a comprehensive perspective of industrial governance to combine the IT infrastructure ability with the business benefits. To face the challenge of improving competitiveness we need increase both enterprise and IT system agility and interoperability.

At a business layer, governance aims at managing business process, leading to BPM approaches. There is widespread usage of the terms Business Process Management (BPM) and SOA interchangeably. According to Gartner [START_REF] Hill | Gartner's position on business process management[END_REF], Business Process Management "organizes people for greater agility," while SOA "organizes technology for greater agility." Business processes need to adapt to changes in the operating conditions and to meet the service-level agreements (SLAs) with a minimum of resources. According to Toyota case study, business processes hide inefficiencies. One has to follow the flow of information as the design evolves into the finished product [START_REF] Ryan | A computer scientist's introductiory guide to business process management (BPM)[END_REF]. Another good example of the benefits of BPM is the classic Ford case, from Hammer and Champy's seminal work [START_REF] Michael | Re-engineering work: Don't automate[END_REF].

With the recent economic turmoil, there is a trend of practically applying Lean 6 six sigma principles into industrial organization. This trend of combining six sigma quality with lean speed, which needs comprehensive governance methods to govern business, services and infrastructure performance, and clear interdependence of different layers' non-functional properties.

To overcome existing technological and organizational limits and lead the trend of utilizing Lean Six Sigma theory into collaborative industrial, we propose a multi-layer industrial service governance method to meet the ever-changing business requirements. It gives a global perspective of industrial governance, includes business level governance, service level governance and IT infrastructure governance. This comprehensive governance architecture could eliminate monitoring blind spot lead to eliminate waste and defects. With this governance method, industrial organization could achieve goals of Lean six sigma and their ultimate business requirements.

Contributions

Overview of our Multi-tier Governance Architecture

Our multi-tier governance architecture is designed to set a global governance environment to avoid any monitoring blind spot and could increase both enterprise and information system agility and interoperability, narrow the gap between business, service and infrastructure, reducing wastes and errors, enhancing the robustness of industrial multi-layer architecture and contribute to some commercial value. We organize a global multi-tier governance architecture used to support both functional and non-functional management. Functional management deploys management engines to achieve functional requirements. Non-functional management cooperates with functional management and deploys performance indicators to evaluate performance of business processes.

To combine and orchestrate all the elements, we organize our multi-tier governance architecture as this way:  BLA as a guide to comply with the Business Quality Standards which could assist companies control quality (include manufacture quality and service quality) and maintain a high standard of customer satisfaction. BLA keeps the two key principles for company: "fit for purpose-the product and service should be suitable for the intended purpose; and right first time-mistakes should be eliminated."  SLA in our multi-tier governance architecture is beyond the normal SLA in SOA.

 A presentation
Our SLA is not only a negotiated agreement between service customers and extern service providers, but also it is the evaluation criteria for quality of service within our multi-tier governance architecture.  ALA lists the expected functional and non-functional properties in application level. It set out the policies, strategies, specifications and criterion of application level. ALA defines all acceptable performances of infrastructure. It plays an important role for Application level indicators to measure performance of applications in this layer.

Non-functional Governance Working Principles

In order to make use of Lean 6 sigma theory to increase business efficiency, we should make sure every operation can add value to end customers, and we should eliminate any extra steps which cannot create profit to enterprise, the value flow and working operation steps of enterprise (from input raw material to distribute outputs through manufacture factor, must be taken into account). Attributes of Functional Requirements and Non-functional Requirements: Functional Requirements (FRs) satisfy clients' business requirements; each 'business requirement' is completed by series Tasks; each 'task' is completed by some 'actions' at each level. Non-Functional Requirements (NFRs) constrain FRs. NFRs are divided into different NFRs-Families and NFRs-classes, according to the feature of NFRs. "FR", "action" and "NFR" could be defined and identified by their attributes. "Taskstamp" is synchronized with current task. "Level mark" labels a certain level. "Family mark" identifies NFPs belong to specific NFRs-Family and "class mark" identifies NFPs belong to specific classes. Therefore "family mark" and "class mark" are flags to automatically link relevant NFPs cross this multi-tier architecture. (Fig. 3) In order to make non-functional governance strategy convenient to retrospect governance situation and expediential to locate and correct mistakes, we take each "task" as a unit to govern and to give report. For each task, each level-indicator provides the real-time level governance report. Aggregators according to NFRs' feature to combine relevant scattered of level governance results to aggregate comprehensive governance results. After that the CI integrates and analyzes aggregators' reports, provides a comprehensive report to users by dashboard. Users can modify the way dashboard shows the governance results, such as users can choose charts or data to display timely governance results. As well as, dashboard can be customized to display level governance results or comprehensive business performance. All governance reports are business readable and non-programming.

Figure 4 gives us the horizontal and vertical view of this non-functional governance architecture's working principles. We can see that this non-functional governance architecture monitor completion performance of each task horizontally, and it monitor the completion performance of entire business requirement vertically.

The combination strategy of BLI, SLI and ALI plays an important role in this multi-tier architecture. According to the classification of NFRs, all of relevant NFRs cooperatively constrain FRs. Following picture gives us an example of NFRs' connection: NFRs in NFR-family (T) and NFR-class (RT and ET), these related NFRs could comprehensively constrain FRs cross three levels. (See figure 5)

This multi-tier governance architecture has ability of position precise governance point, and it has ability to evaluate any operation step could or not bring value to end users. It will improve agility of business and technologies. If there is any problem impedes value flow smoothly through entire enterprise, this architecture could find it out and fix it without impact other normal value flow steps.

Conclusion

In this ever-changing economic environment, an ideal governance method could be significant for enterprises to achieve their business goals, to realize business and IT agility, to maximize their profits, to close the gap between business and IT, to eliminate wastes, to improve customer satisfaction, to enhance enterprises' comprehensive competitiveness, to win the future. According to the importance of governance architecture, we propose a multi-tier industrial governance architecture, which relies on the ability of linking dynamically industrial services in a customized industrial organization to fit the client requirements. This approach partly inspired by the Lean Six Sigma vision, extends the horizon of SOA to reveal a global vision, the enterprise business organization, abstract service network and its information infrastructure could be more agile.

Fig. 1 .

 1 Fig. 1.

Fig. 2 .

 2 Fig. 2. Overview of Multi-tier Governance Architecture

Fig. 3 .

 3 Fig. 3. Relation and Attributes of FRs, NFRs, Tasks and Actions

Fig. 4 .

 4 Fig. 4. Details of Horizontal and Vertical view of Governance

Fig. 5 .

 5 Fig. 5. Connection of Related NFRs

Acknowledgments

This work extends the service showing strategy of the project process 2.0 granted by the DGCIS.


Roberto Morabito

Riccardo Petrolo

Valeria Loscrì

Nathalie Mitton

Giuseppe Ruggeri

Antonella Molinaro

Lightweight Virtualization as Enabling Technology for Future Smart Cars

Keywords: Internet of Things, Smart Vehicles, Internet of Vehicles, Virtualization Technologies, Container

Modern vehicles are equipped with several interconnected sensors on board for monitoring and diagnosis purposes; their availability is a main driver for the development of novel applications in the smart vehicle domain. In this paper, we propose a Docker container-based platform as solution for implementing customized smart car applications. Through a proof-of-concept prototype-developed on a Raspberry Pi3 board-we show that a container-based virtualization approach is not only viable but also effective and flexible in the management of several parallel processes running on On Board Unit. More specifically, the platform can take priority-based decisions by handling multiple inputs, e.g., data from the CANbus based on the OBD II codes, video from the on-board webcam, and so on. Results are promising for the development of future in-vehicle virtualized platforms.

I. INTRODUCTION

Nowadays, modern vehicles are equipped with very sophisticated electronic systems and associated in-vehicle communication infrastructures, aimed to provide different functionalities which vary from engine control, predictive diagnostics, driving assistance, and infotainment. Implementing new functions requires more and more computing and communication resources to be installed on board. As an example, the increasing demand of safety boosted the trend to equip vehicles with single and multiple cameras that transfer recorded videos on the vehicle bus, to be processed by the On Board Unit (OBU) [START_REF] Lim | Challenges in a Future IP/Ethernet-based In-car Network for Real-time Applications[END_REF]. Furthermore, the recent development of Social Vehicular Networks [START_REF] Vegni | A Survey on Vehicular Social Networks[END_REF] is another driver for the increase in the amount of generated data. By envisaging innovative real-time applications in next generation vehicles, we realize the great impact that an efficient and effective use of the bandwidth can play for the always-increasing bandwidth demanding applications.

The expectation for the near future is the above described trend to grow, fueled by the recent sales boom in the automotive market that has also revamped research funding on this topic [START_REF] Ulrich | 2016's Top Ten Tech Cars[END_REF]. In spite of such favorable perspectives, there are still many open issues and challenges to be addressed. Nowadays, OBUs are embedded systems with limited resources and hardly modifiable. Software updating of an OBU requires a long and cumbersome procedure to be carried out in a properly equipped workshop. This hardness combined with the typical software lifetime, which is much shorter than the lifetime of mechanical components, may result in a rapid obsolescence of modern vehicles. It is therefore crucial to devise a suitable mechanism to make OBU programming (and re-programming) easier. Also, the limited resources of current OBUs may be the cause of long latency in carrying out time-critical tasks. A clever way to manage resources and allocate them to more critical tasks is necessary. In this context-which is continually evolving-an efficient OBU design has to meet a number of requirements that makes the OBU updating process easier, enable the deployment of new software, and efficiently manage parallel processes with real-time constraints.

In this work, we investigate the potentialities of lightweight virtualization as enabling technology for the fulfillment of the aforementioned requirements. Docker 1 is an open-source container-based virtualization technique, easy to use and deploy, which represents a mandatory feature for applications development in modern smart vehicles. This feature also brings high flexibility, allowing flexible "activation" and "deactivation" of processes with a minimal impact in terms of overhead.

To achieve our objectives we follow a pragmatic approach and address two main points. First, we design a feasible architecture for a virtualized OBU and we illustrate how common vehicular applications can be implemented on it, while outlining the guidelines to extend our approach to a generic implementation. Second, we evaluate the achievable performance to assess if virtualization has caused some detrimental effect and to which extent this natural decay in performance remains within tolerable margins.

The main contributions of this paper can be summarized as follows:

• we propose the use of Docker containers in order to customize a smart car platform [START_REF] Morabito | Demo: Design of a Virtualized Smart Car Platform[END_REF] and make it compliant with different end user requirements;

• we show how efficiently using containers to instantiate and schedule dedicated applications according to the vehicle status and/or on-demand services;

• by means of an empirical evaluation, we demonstrate that the proposed lightweight virtualization technique developed on top of devices with limited computational capability-such as a Raspberry Pi3-has an almost negligible adverse impact in terms of performance, also under heavy and heterogeneous workload conditions, and it allows the end user to dynamically add/eliminate running processes according to his/her needs.

To the best of our knowledge, this is the very first contribution that shows the real implementation of a container-based virtualization technique in the context of smart cars.

The rest of the paper is organized as follows. In Section II, we overview the main contributions related to our work and highlight the rationale behind our proposal. In Section III, we describe the architecture of the proposed container-based platform. Section IV describes the performance of our platform. Finally, Section V concludes the paper by also identifying potential extensions of our architecture to other interesting scenarios.

II. RELATED WORK AND MOTIVATIONS

Docker open-source "containerization" is gaining consensus in several research and industrial domains as a lightweight virtualization technique alternative to more traditional Virtual Machine (VM) based approaches. In [START_REF] Xavier | A Performance Isolation Analysis of Disk-Intensive Workloads on Container-Based Clouds[END_REF], the Docker performance is shown and interesting recommendations are given on the use of different disk-intensive workloads on containerbased clouds. In [START_REF] Felter | An updated performance comparison of virtual machines and Linux containers[END_REF], the authors draw similar conclusions claiming that both VMs and containers are mature technologies and introduce negligible overhead for memory and CPU performances, with Docker generally achieving equal or better performance than Kernel VMs [START_REF] Kivity | KVM: the Linux Virtual Machine Monitor[END_REF]. Analogous conclusions can be found in [START_REF] Raho | KVM, Xen and Docker: A performance analysis for ARM based NFV and cloud computing[END_REF] and [START_REF] Morabito | Hypervisors vs. lightweight virtualization: a performance comparison[END_REF], where traditional hypervisors and container-based solutions are compared. Since VMs share the hardware resources while containers share the operating system, this makes solutions like Docker easier to use and faster to deploy. These features make Docker a suitable "containerization" solution for the creation of an embedded versatile device able to manage smart car applications.

Container-based virtualization has been recently considered in the vehicular domain. In [START_REF] Masek | Container Based Virtualisation for Software Deployment in Self-Driving Vehicles[END_REF], a container-based approach is considered for self-driving vehicle applications with hard safety and timing requirements. Of course, given the realtime constraints of this application domain, any additional overhead could affect the system performance and introduce more latency, that could result in software malfunctioning. A different perspective has been considered in [START_REF] Tuohy | Hybrid testbed for simulating in-vehicle automotive networks[END_REF], where the authors present a network simulation method in the vehicular context. Their platform, exploiting both simulated and real network data traffics with the use of lightweight containers, has been tested by considering two Ethernet topology-Double Start and Daisy Chain-in order to conclude that also in the case of high workloads (i.e., 6 in-vehicle cameras broadcasting simultaneously, along with control infotainment and other types of traffic) the delay requirements for safety-critical video information may be violated.

Our approach differs from the previous ones under several aspects. We design and implement an embedded all-in-one Cyber-Physical-Device for smart car applications and contribute with a real prototype based on a Raspberry Pi 3 that is connected with the On Board Diagnostic (OBD) system of a car. We show how we can make it coexisting with other processes that span from infotainment applications to video data delivery (e.g., from a webcam mounted on top of our device), etc. To the best of our knowledge, this is the first real implementation of a Docker container-based prototype for vehicular applications. The interest behind this type of implementation is demonstrated by projects like Carberry2 , where a Raspberry Pi includes CAN bus, Gmlan, IR Led input, etc. The main and important difference of our approach with regard to these projects consists in the exploitation of Dockerbased virtualization that, as we will show, gives very high flexibility to the final system that can be easily expanded with novel processes and enriched with new features.

III. SYSTEM DESIGN AND IMPLEMENTATION

In this section, we first introduce the technologies used in the implementation of our prototype. Then, the entire platform architecture will be described in detail. Finally, through the analysis of different examples, we show how the main benefits introduced by container technologies can boost the development of a versatile and flexible platform.

A. Enabling Technologies

Raspberry Pi (RPi) is a single-board computer that leverages the low-power low-cost ARM processor architecture [START_REF] Smith | ARM and Intel battle over the mobile chip's future[END_REF] and became popular thanks to its flexible use in several contexts. Raspberry Pi has been already used in in the vehicular context in projects like CarBerry and in OBD-Pi 3 . For the development of our platform, we selected the last generation of the Raspberry Pi, which is the Raspberry Pi 3 (RPi3) model B3. The main hardware characteristics of the board are summarized in Table I. Data coming directly from the vehicle can be read through the OBD-II standard [START_REF]15765-2004 Road Vehicles -Diagnostics on Controller Area Networks (CAN)[END_REF] interface that provides two types of data: real-time vehicle data and several Diagnostic Trouble Codes (DTCs). The entire subset of such data can be efficiently used in order to monitor the current operating status of a vehicle, and to identify malfunctioning in the vehicle itself.

B. Functional Modules

The architecture of our prototype is depicted in Fig. 1. The platform has been designed to meet specific requirements: (i) fast allocation and flexibility in managing different services; (ii) isolation; (iii) backup capabilities. In the following, each key component is described in detail. The Hardware is a Raspberry Pi 3 board used to develop our platform. A key aspect that led us to the choice of the Raspberry Pi platform is its capability to efficiently run virtualized applications through the use of container technologies, in particular Docker. Furthermore, the ease with which different applications can be managed through containers well match our platform requirements. Finally, as demonstrated in [START_REF] Morabito | A performance evaluation of container technologies on Internet of Things devices[END_REF], the introduction of the virtualization layer in devices with low computational resources does not adversely impact the performance.

As base Operating System we use the image provided by Hypriot running Raspbian Jessie with Linux kernel 4.4.10, with Docker version 1.12.0. As storage device, a 16 GB (Transcend Premium 400x Class 10 UHS-I microSDHC) memory card has been used.

At the application level, our architecture entails three main components: (i) a set of singularly virtualize applications tagged with different priority levels; (ii) an OBD Container that is in charge of receiving and handling the data from the vehicle; and (iii) the Orchestrator that has the task of monitoring the resources used by the entire system and by each virtualized application. Orchestrator and OBD are in the same functional block since they frequently interact. The central role played by the Orchestrator component will become clearer in the following sections.

We defined four application/service types (Fig. 2):

• Critical priority applications are characterized by the highest level of priority (e.g., applications dedicated to firmware update/restore, or demanding control data).

• High priority applications, which include e.g., driver assistance, camera data.

• Moderate priority applications consist of applications provided by auto insurance companies, which offer reduced premiums if OBD-II vehicle data loggers 4 are installed.

• Low priority applications include Entertainment/Multimedia contents streamed by an internal and/or external device.

In defining the priorities, we refer to the application requirements in [START_REF] Lim | Challenges in a Future IP/Ethernet-based In-car Network for Real-time Applications[END_REF]. Since the Raspberry Pi is a low-resource device with limited computation capabilities, specific allocation policies have to be defined and executed by the Orchestrator in order to give priority to the execution of a virtualized application over another. For each level of priority, an application that provides backup functionality is planned. This implementative choice is done by considering that possible malfunctions recorded by the OBD-II can have different priorities. One of the key roles played by the orchestrator is to determine how many resources are employed by the running applications, and verify that the whole system is compliant with the priority of all the active instances. Furthermore, by acting as application manager, the orchestrator is responsible for the allocation of new instances.

In order to answer the needs of all hosted instances, the scheduling of new applications on the OBU has to consider three different aspects:

• priority of the instances already running;

• priority of the incoming instances;

• hardware resources already employed;

For estimating the used resources on the physical node, we refer to the Volume metric introduced by Wood et al. in [START_REF] Wood | Sandpiper: Black-box and gray-box resource management for virtual machines[END_REF]. This metric considers that a physical node can be loaded along one or more of three dimensions-CPU, network, and memory. The volume expresses how much the system is (over)loaded along multiple dimensions in combined way, and can be used to fairly estimate all resources used by each component. Equation 1 defines this metric; cpu stands for the normalised CPU usage, mem for memory, and net for network.

The higher the utilization of a resource, the greater the volume. As a consequence, if multiple resources are heavily utilized, the above product results in a correspondingly higher volume.

V ol = 1 1 -cpu × 1 1 -mem × 1 1 -net (1)
Moreover, the Docker remote API allows us to quantify the instant use of the three dimensions for each running container. Therefore, we are able to quantify the Volume generated by each individual container (Eq. 2).

V ol contn = 1 1 -cpu contn × 1 1 -mem contn × × 1 1 -net contn (2)
The overall Volume can be furthermore characterized by Equation. 3. Resources employed by each virtualized application are quantified, with the addition of the volume due to the basic processes.

V ol = n i=1 V ol conti + V ol base (3)
Once outlined how to estimate the resources employed by the whole system and by each virtual component, hereafter is described how a new application is allocated in the system.

The orchestrator keeps memory of all the running applications and their associated priority. As soon as the request for a new instance allocation arrives, the orchestrator has to consider the priority associated to the incoming request, together with available resources on the physical node. If the available volume is greater than a certain threshold-which can be set according to the number of applications that are expected to be handled in total by the device-the new application is instantiated on top of the device. Otherwise, the discriminating factor for the instantiation of the new application is given by its own priority. Indeed, if the priority of the incoming request is set to critical, the orchestrator acts so as to guarantee the necessary resources for the execution of the application. If there are no available resources and the priority is not critical, the application request is entirely rejected. In the next subsection, the dynamic service allocation is further explained.

C. Application Scenarios

The Orchestrator dynamically allocates applications/services in the platform. This feature brings several benefits in terms of resource usage. Indeed, the container instances can be instantiated only when required or when specific events like a car operating anomaly occur.

For example, we analyze the case of an anomalous gas emission detected by the OBD (corresponding to the OBD code P0442). According to our requirements, the system must store in memory what happens at the time when the anomaly has been detected. The dynamic allocation of a container dedicated to this purpose will provide a detailed snapshot of the evolution of this anomaly. In practice, as soon as the orchestrator-which constantly receives data from the OBDdetects the anomaly, it executes the activation of another virtualized application dedicated to the execution of a particular task. Referring to this example, a database is initialized in order to record all the parameters associated to the evaporative (EVAP) emission system (Fig. 3).

In the second example (Fig. 4), we consider the case in which the OBD detects a sudden vehicle speed decrease. This particular situation may correspond to an imminent danger. Also in this scenario, the Orchestrator can activate a container, which in turn starts the video recording of the surroundings through the camera connected to the Raspberry.

The aforementioned examples show how the flexibility related to the use of containers in this context enlarges the potentialities of our platform in terms of backup functionality and capacity of running-dedicated applications at given times. Flexibility can also be used to optimize the performance of the platform itself. Considering that the number of applications that can simultaneously run on top of the RPi3 is limited, the definition of different priorities, together with the dynamic management of containers, is also useful to schedule which application takes priority when the hardware resources are kept busy.

To better explain how containers can help on pursuing this goal, we suppose that two applications characterized by different priority levels, e.g., Moderate and Low, are simultaneously running. Similarly to the previous examples, the Orchestrator recognizes a possible critical status for the vehicle by means of data received by the OBD. The platform has to guarantee the execution of a specific application that can somehow help on solving and/or tracing the vehicle behavior during the critical status. At the same time, it has to be fast on reacting to this potential dangerous. Considering that the execution of this task has the highest priority, all the concurrent instances that are running on that given time have to be paused to make available all the resources to the application marked by critical priority. This can be easily achieved thanks to the Docker API, which allows every running container to pause (and un-pause). When the containers are in pause mode, no hardware resources are employed.

IV. PERFORMANCE EVALUATION

The validation of our proposal covers two different aspects. First, we evaluate how a Raspberry Pi reacts, in terms of performances, to specific workloads generated by applications running within Docker containers. This operation lets us to quantify potential overhead introduced by the virtualization layer. Then, we present a first performance evaluation of our platform while performing specific tasks.

A. General Performance

The impact of virtualization of Docker on ARM devices has been already discussed in [START_REF] Morabito | A performance evaluation of container technologies on Internet of Things devices[END_REF]. However, in this work the performance evaluation is carried out by means of benchmark tools that stress specific hardware segments of the device. Although this is a reasonable approach-which enable to assess an upper-bound to the performance of each system hardware portion-it can not be neglected that real-world applications challenge the hardware in a more distributed way. For this reason, we decide to evaluate the impact of virtualization on Raspberry 3 by means of the stress 5 benchmark tool, which is a workload generator that allows to allocate a configurable amount of CPU, memory, I/O, and disk stress on the system. This analysis also aims to evaluate the behavior of the Raspberry when it is subjected an increasing workload. For this purpose, we have defined four different workload levels: 5 http://manpages.ubuntu.com/manpages/wily/man1/stress.1.html

Workload Description Base

A load average of one is imposed on the system by specifying one CPU-bound processes.

Low

A load average of two is imposed on the system by specifying one CPU-bound processes, and one memory allocator process.

Average

A load average of three is imposed on the system by specifying one CPU-bound processes, one memory allocator process, and one disk-bound process (50MB).

High

A load average of four is imposed on the system by specifying one CPU-bound processes, one memory allocator process, and one disk-bound process (100MB).

(i) Base load; (ii) Low Load; (iii) Average Load; (iv) High Load. Table II shows more details about the four generated workloads.

The performance metric that we are interested in monitoring is the system load, which indicates the overall amount of computational work that a system performs. The average load represents the average system load over a period of time. In our evaluation, such time interval is set to 400 seconds. We decided to use the system load average metric, as it includes all the processes or threads waiting on I/O, networking, database, etc. [START_REF] Walker | Examining load average[END_REF]. This process can help us to well characterize the platform performance, by taking into account the heterogeneous features of the applications that run on top of it. The aforementioned metric can be monitored by means of Unix tools like dstat 6 . This tool calculates the average load and provides three values for it referring to the past one, five, and fifteen minutes of system operation. In our experiments, we only consider the 1-minute average system load. Each test is started when the RPi3 shows a load number of 0.

To better understand what this metric expresses, we can consider the example of a single-CPU system that shows a 1minute load average of 1.46. This means that during the last minute, the system was overloaded by 46% on average-1.46 runnable processes, so that 0.46 processes had to wait for a turn for a single CPU system on average. In other words, this also means that a system load average equal to one represents an upper-bound for this metric in a system with one CPU, after which the Operating System could behave unstably. Similarly, a system average load equal to four represents the upper-bound in a system with four CPUs.

In our evaluation, the native performance-i.e., running the stress tool without including any virtualization layer running on top of the underlying hardware-is used as a reference for comparison. This will be useful to quantify a possible overhead introduced by container technologies on the Raspberry Pi. Fig. 6 shows the result of the General Performance test. Several insights about the performance impact introduced by Docker can be drawn. First, it can be noticed how for three of the four workloads (base, low, and average), native and Docker performance curves basically overlap. This represents 6 http://dag.wiee.rs/home-made/dstat/ an important outcome since it confirms the lightweight characteristics of container technologies, even when the RPi3 has to handle mixed workload.

The only case in which a tangible overhead between native and Docker performance can be observed is when a High workload is assigned to the Raspberry. By analyzing the High workload curve, we can notice that Docker reaches earlier the system load upper-bound. The performance difference, between native and Docker performance, can be quantified in the order of the 15%. We can also observe the unstable behavior of the system -both for the native and virtualized cases-when the upper-bound is exceeded. As previously explained, this behavior is attributable to the system overloading. However, it is worthy clarify that the High workload has been defined in such a way to heavily challenge the system. Indeed, when memory and disk-bound processes are imposed to the system, the CPU has extra tasks to be executed. Furthermore, in the next subsection it can be observed how in correspondence of complex workloads, the system load does not reach the value for which there is a not negligible performance overhead between native and virtualized applications.

B. Platform Performance

After showing the efficiency of the RPi3 in handling mixed workload running within Docker containers, we want to test the performance of our platform when it has to manage dedicated virtualized applications. To this end, we have defined a set of workloads that are closely related to the application scenarios described in Section III-C. A detailed explanation of five workloads is provided in Table III. It can be observed how those scenarios are characterized to deliver increasing load to the system. To accomplish this evaluation, we assume that the functional block OBD+Orchestrator is receiving data from the OBD-II interface-which is directly connected through serial port at the Raspberry Pi-every 10 ms. Fig. 7 shows the results for the platform performance evaluation. The main outcome in the platform evaluation lies in the fact that, even when several virtualized instances are simultaneously running, the average system load is lower than the upper bound. The result is the same also for the case of a workload in which there are five containers running different

Workload Description

Workload 1

This workload refers to the simple scenario in which the OBD/Orchestrator container receives data from the OBD-II interface through the CAN bus, and forward the received data to a database in which the OBD logs are stored.

Workload 2

The second workload refers to the case in which the orchestrator has to activate and manage a single virtualized application.

The application handles a video content from a camera directly connected to the Raspberry Pi. The video content is encoded in MPEG-4 format, and made available through to HTTP connection.

Workload 3

The third workload is a combination of Workload 1 and Workload 2.

Workload 4

In the fourth case, we add the streaming of a multimedia content to the Workload 3.

Workload 5

The Workload 5 combines the previous case with the activation of another container that interacts with the connected web-cam for recording and storing (on the MicroSD card) the transmitted video content. services/applications, by enforcing the deployment feasibility of an efficient platform also in terms of scalability.

The only tangible difference between the behaviour introduced with the different workloads is that, when disk operation-such as database writing-are included, the system load average grows introducing a sort of oscillating characteristic. On the contrary, if disk operations are excluded-like in the Workload 2 case-the aforementioned behavior is not observable. Fig. 8 shows the Average and the Maximum values for the System Load. We can observe that the System Load increases with the complexity of the workloads. Taking into account the average value, we are interested on quantify how the increasing workload complexity affects the system load. As an example, there is an increase of approximately 13% between Workload 3 and Workload 4. The percentage increase between Workload 4 and Workload 5 is instead 25%.

As explained above, the system load is a metric that takes into account also the average of the system in a given period of time. However, in Section III-B, we have described the way in which the orchestrator estimates the available resources. We have seen that the volume expresses how much the system is load, by considering the combination of the resources employed by CPU, memory, and networking. Therefore, in order to have hints about the impact of each single dimension in all the different workloads, we have also estimated CPU and RAM usage. Fig. 9 and Fig. 10 show respectively CPU and Memory RAM usage for the different workloads. Similarly to what observed for the system load, an increase linked with the higher workload complexity can be observed. It is interesting to note also that for very complex workloads, e.g. 4 and 5, memory resources are far from saturation. However, this analysis shows how important is to monitor the contribute of each component of the volume, since that, from the knowledge of these, the orchestrator has a precise overview about how the resources are employed. Fig. 11 shows the overall volume characterization, and how each single component affects in it. For our experiments, networking has not been considered-and its contribute in the volume definition set to 1-as there are no relevant network interactions, such as to generate a non-negligible contribution. It must be kept in mind that volume is defined as the product of its CPU, network and memory load. trend, although they grow in different way. Knowledge of both metrics for different workloads can give a more complete description on the platform performance. Indeed, the system load although expresses the performance system without identify the various dimensions, it provides a description about the past state of the system.

V. CONCLUSIONS AND FUTURE DIRECTIONS

In this paper, we have proposed the design of a platform representing a viable and efficient solution for smart car ap-plications. In particular, the prototype that we have developed is based on Raspberry Pi3 and implements a container-based virtualization solution to manage different parallel processes, including the treatment of information generated by the CANbus. The different processes can be opportunistically scheduled based on specific requirements (e.g., the management of alert processes). Through a proof-of-concept testbed we have demonstrated both the feasibility of a smart car design based on Docker virtualization containers and its effectiveness in terms of responsiveness and reactivity of the system. The derived system is customized and compliant with the final user requirements. Nowadays vehicles include a growing number of distributed control units, which provide different services within the car. Such services have different requirements and generate extremely different traffic types. Such a distributed approach has already led to the deployment of in-vehicle networks that include several entities dedicated to the management of heterogeneous applications. Our idea for future work is that the flexibility introduced by containers can help in improving also the resource allocation management of in-vehicle networks. For example, the use of container orchestrator engine such as Docker Swarm7 can be the enabling tool for allocating each container to the most suitable OBU (Fig. 13).

Fig. 1 .

 1 Fig. 1. Platform architecture.

Fig. 2 .

 2 Fig. 2. Functional modules.

Fig. 3 .

 3 Fig. 3. Data Base Container activation.

Fig. 4 .

 4 Fig. 4. Dash Cam container activation.

Fig. 5 .

 5 Fig. 5. Anomaly detected case.

Fig. 6 .

 6 Fig. 6. General performance.

Fig. 7 .

 7 Fig. 7. Platform performance characterization for different workloads.

Fig. 8 .

 8 Fig. 8. Average and Max values for System Load evaluated in 1-min.

Fig. 9 .

 9 Fig. 9. CPU usage for each Workload.

Fig. 12 Fig. 10 .

 1210 Fig.12shows the comparison between volume and system load. It can be observed how the two metrics follow the same

Fig. 11 .

 11 Fig. 11. Volume characterization.

Fig. 12 .

 12 Fig. 12. Volume vs System Load in 1-min comparison.

Fig. 13 .

 13 Fig. 13. Future work.

TABLE I .

 I RASPBERRY PI 3 HARDWARE FEATURES.

	Parameter	Description
	Chipset	Broadcom BCM2837
	CPU	Quad Core @900MHz ARMv7 Cortex-A7
	Memory	1GB LP-DDR2 900 MHz
	GPU	Broadcom VideoCore IV
	Ethernet	10/100 Mb/s
	Flash Storage	MicroSD
	Connectivity USB 4 USB 2.0 Host
	OS	Linux, Windows 10
	Price	$35

TABLE II .

 II WORKLOAD CHARACTERIZATION FOR GENERAL PERFORMANCE ANALYSIS.

TABLE III

 III

	.	WORKLOAD CHARACTERIZATION FOR PLATFORM
		PERFORMANCE ANALYSIS.

http://www.docker.com/

http://www.carberry.it

http://www.instructables.com/id/OBD-Pi

https://www.progressive.com/auto/snapshot/

https://www.docker.com/products/docker-swarm

ACKNOWLEDGMENT

This work is partially supported by CPER DATA, the FP7 VITAL project, and by the FP7 Marie Curie METRICS project.


𝐴𝑏𝑑𝑜𝑢𝑙𝑤𝑎ℎ𝑎𝑏 𝐴𝑑𝑎𝑖𝑛𝑒 1,2,* 𝑆𝑖𝑑𝑖 𝑂𝑢𝑙𝑑 𝑆𝑎𝑎𝑑 𝐻𝑎𝑚𝑎𝑑𝑦 1,2 𝑁𝑖𝑐𝑜𝑙𝑎𝑠 𝐹𝑟𝑒𝑠𝑠𝑒𝑛𝑔𝑒𝑎𝑠 1,2 1 Université de Lorraine, Laboratoire Matériaux Optiques, Photonique et Systèmes, Metz, F-57070, France 2 Laboratoire Matériaux Optiques, Photonique et Systèmes, CentraleSupélec, Université Paris-Saclay, Metz, F-57070, France *abdoulwahab.adaine@univ-lorraine.fr A detailed investigation on the performance of an InGaN-based double-junction solar cell was carried out. We have globally simulated the solar cell using empirical InGaN material parameters, to avoid any overestimation in the solar cell performances. In order to take into account the interdependence of the solar cell physical and geometrical parameters, ensuring the absoluteness of the optimized photovoltaic performances, the cell was optimized using a multivariate optimization algorithm that simultaneously optimizes eleven physical and geometrical parameters. We obtained an optimal efficiency of 24.4%, with a short circuit current J SC = 12.92 mA=cm 2 , an open circuit voltage V OC = 2.287 V and a fill factor FF = 82.55%. We then quantitatively investigated the impact on the solar cell performances of the internal polarization and structural defects in InGaN. We have shown that the internal polarization reduces the performance of the cell by inducing an electric field which does not favor an efficient collection of photo-generated carriers. We have also investigated the impact of structural defects in InGaN, including disorder and deep defects, and correlated their effect to the InGaN doping concentration.

Influence of defect and polarization on efficiency of InGaN-based double-junction solar cell

Multivariate Optimization

 The polarization charges in the solar cell bend the conduction band at the interface between the tunnel junction and subcell-2; the bend curvature increasing with the polarization. This causes charges to accumulate at this interface, which in turn create an electric field. This field, induced by the polarization, is in the opposite direction to that of the PN junction internal field.

It thus tends to lower the total integrated electric field in the cell, which explains the decrease in the performances of the solar cell.

Variation of efficiency as a function of the Urbach energy of the band tail.

Variation of efficiency as a function of the decay energy of the Gaussian distribution.

The increase of the Urbach energy implies a reduction in the optical gap owing to the presence of states in the InGaN bandgap, leading to a higher probability of carrier recombination. In the same way, for the deep states, the increase of the decay energy also leads to an increase of the state density in the bandgap and therefore to a higher probability of recombination of the carriers. Both these effects thus result in the decrease of the short circuit current (J SC ) and therefore a decrease in the efficiency of the solar cell.

It can be noted the an increase in the disorder in the Urbach energy degrades the solar cell performances much more than a deep states decay energy increase. Thus, in InGaN solar cells, material disorder is therefore more detrimental to the performances of the solar cell than deep defects states.

 Carrier Mobility  Carrier Recombination  Index of refraction  Absorption coefficient



   Subcell-1, absorbs high-energy photons  Subcell-2, absorbs lower energies photons  The Solar cell absorbs a larger solar spectrum than a single junction cell InGaN-based double-junction solar cell  Structure composed of two p-n junctions  Two subcell vertically stacked having different bandgaps Tunnel junction  The two subcells are connected by a tunnel junction to enhance current matching between the subcells  X 1 , X 2 and x 3 Indium composition of subcell-1 , subcell-2 and tunnel junction respectively Obviously the optimization problem becomes more complex with so many variables  Optimization method with a higher-order convergence  Ensure the overall convergence of the optimization method The short-circuit current, 𝑱 𝑺𝑪 = 𝟏𝟐 . 𝟗𝟐𝒎𝑨/𝒄𝒎 𝟐 The open-circuit voltage, 𝑽 𝑶𝑪 = 𝟐. 𝟐𝟖𝟕 𝑽 Fill factor, 𝑭𝑭 = 𝟖𝟐.55 Optimal efficiency and the significant parameters of the solar cell Ƞ=24.4% 11 Optimization parameters concerns the dopings and the thicknesses of the 2 subcells and the different indium compositions (𝑥 1 , 𝑥 2 , 𝑥 3 ).

  Simultaneously optimizing of several physical and geometrical parameters  Much more rigorous than single parametric analysis  Suitable for next generation solar cell  Optimum efficiency as a function of several optimization parameters  Sage/Scipy  We use the Sage software interface to the Scipy optimizers  Open source free sofware  Coded and optimized by computer experts Simulation Current-voltage characteristics with different polarization charges. Conduction band diagrams in the tunnel junction with different polarization charges.