Pooling of Heterogeneous Computing Resources: A Novel Approach

based on Multi-Edge-Agent Concept

Florent Carlier

1 a

, Virginie Fresse

2 b

, Jean-Paul Jamont

3 c

, Loic Pallardy

and Arnaud Rosay

4 d

Centre de Recherche en

Education de Nantes and Le Mans University, Le Mans, France

Laboratory Hubert Curien UMR CNRS 5516 and University of Jean Monnet, Saint-

Etienne, France

Laboratory LCIS, Univ. Grenoble Alpes, Grenoble INP, Valence, France

STMicroelectronics, Le Mans, France

Keywords:

Architectures for Vehicular, Multi-Agent Systems, Edge Computing Approach, IoT-a, Avatar.

Abstract:

Advanced driving assistance systems are major innovations in vehicles requiring more and more electronic

systems both inside and outside cars and trucks and using vehicle to vehicle and vehicle to infrastructure com-

munications. Electric/Electronic architecture of modern vehicle is based on clustering of Electronic Control

Units (ECU) either by domain or by physical location. Innovation in the ﬁeld of transportation is often related

to the introduction of new software requiring the addition of hardware. This is a barrier to disseminate innova-

tion in existing vehicles. The most appropriate solution to overcome this problem consists in fully exploiting

under-utilized computing resources rather than adding new ones. In this paper, we propose a novel approach to

manage a pool of resources by introducing the concept of EdgeAgent model. Pooling of resources is managed

by three types of EdgeAgents: Mediator, Allocator and Processor. The resulting system architecture is based

on IoT-a (agents as close as possible to hardware) and Avatar (virtualizing the representation of the hardware

in high level: Cloud and Edge computing). The result of this work enables extension of vehicle management

and functionalities while considering the environment for vehicles of the future.

1 INTRODUCTION

More and more intelligence is integrated inside ve-

hicles to enhance driving safety and increase engine

performance efﬁciency. The objective of car design-

ers and manufacturers is not only to propose au-

tonomous driving vehicles but also to add new fea-

tures, increasing the level of automation from the

level zero, where humans do the driving, up to level

ﬁve through driver assistance technologies up to fully

autonomous cars. Adding more and more features

leads to raise the electronic computing power. The

basic mundane solution is to increase the number of

electronics components to execute these applications.

As an example, Renesas sells hardware and software

platforms to cover the full product range from the pre-

mium class to the entry level. These platforms con-

https://orcid.org/0000-0003-0314-3667

https://orcid.org/0000-0002-9944-0174

https://orcid.org/0000-0002-0268-8182

https://orcid.org/0000-0001-5937-5331

tain Systems On Chip (SoC), an integrated circuit in-

tegrating several components on one single substrate

(SA, 2019). This was a viable solution as SoCs con-

sume much less power and take up much less area

than multi-chip designs. Adding SoCs for new fea-

tures was possible in vehicular electronics in the past

but cannot be considered in this way anymore. The

use of lightweight materials within road vehicles has

been considered for many years. Challenges in car

manufacturing are to lightweight the cables, reduc-

ing copper wiring looms by grouping multiple legacy

buses on a single Ethernet backbone, and now to op-

timize electronics to reduce energy consumption and

weight of vehicle. Although the number of electronic

features is set to grow signiﬁcantly, the actual value of

components should not signiﬁcantly change. With the

high number of microprocessors and micro-controller

in vehicles, distributing the workloads is the new

challenge. Such challenge requires to propose new

approaches to manage the vehicle electronics in the

present and in the future. Similar approaches have

been already proposed in literature and in industry

Carlier, F., Fresse, V., Jamont, J., Pallardy, L. and Rosay, A.

Pooling of Heterogeneous Computing Resources: A Novel Approach based on Multi-Edge-Agent Concept.

DOI: 10.5220/0008954301850192

In Proceedings of the 12th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2020) - Volume 1, pages 185-192

ISBN: 978-989-758-395-7; ISSN: 2184-433X

185

for other application contexts. The emergence of the

Cloud Computing, Internet of Things and Edge com-

puting approaches aim at virtualizing, sharing and de-

ploying resources to optimize the workloads and re-

sources usage. The aim of this paper is to propose

a similar approach in vehicle electronics, by predict-

ing the evolution of vehicle architectures and power

requirements from nowadays and future solutions.

The paper is organized as follow. The futuristic

motivating scenario and the predicted vehicle elec-

tronics are presented in section two to extract future

challenges. In a third section, we propose an approach

based on the use of edge agent to carry out mediation

and task allocation on Processing Units. In a next sec-

tion, we describe the system architecture that supports

our approach. It is based in particular on the use of ex-

isting architectures: avatars and IoT-a. In conclusion,

we propose to position ourselves in the context of the

edge. We discuss the limits of the use of avatar and

IoT-a architectures and end our discussion with rec-

ommendations for a new architecture that we wish to

propose in the near future.

2 MOTIVATING SCENARIO

Most actual vehicles integrate a lot of in-vehicle ser-

vices and a small number of out-vehicle services. In-

novative services aim at enabling the car users to

be better informed, be safer, more coordinated with

its surroundings and to offer a smarter use of trans-

port network. Therefore Intelligent Transportation

System and Smart City will be more and more cou-

pled to transform urban mobility. Vehicle-to-Vehicle

(V2V), Vehicle-to-Infrastructure (V2I) and Vehicle-

to-Roadsign (V2R) technologies will be rolled out,

and some services oriented architecture such as which

data ﬁltering and fusion functionalities will be dele-

gated either to the cloud or to external environment.

In-vehicle services will have to consider context-

aware applications. For example, effective infotain-

ment system will use the latest (live) information for

enhanced user experience. The connected car will

serve as a communications hub that will transmit as

well as receives data and information, for diagnosis

and driving assistance system (by reinforcing deep

learning application for example).

The trend toward connected cars will cause dis-

ruption and create new opportunities in areas for Ad-

vanced Driving Assistance System, Advanced Traf-

ﬁc Management System, Advanced Traveler Informa-

tion System, Advanced Vehicle Control System, Ad-

vances Diagnosis and Maintenance System and Ad-

vanced Infotainment System.

Figure 1 depicts one created scenario for future

urban mobility in dense and developed cities. The ve-

hicle is connected to other vehicles and to external

passive and active devices to help the driver.

All these systems interact and are connected to-

gether to offer relevant and appropriate services. For

example, the steering system today interact with the

suspension to ensure a smooth ride and in the future

buildings will interact with the trafﬁc management

system to plan ahead the daily journeys.

The objective of the motivating scenario is to pre-

dict the electronic requirements of the vehicles of the

future from actual electronics. The existing system is

studied to consider the likely evolution of the system

according to the predicted advanced system presented

in the scenario.

Electronics in vehicle typically contains 100-300

micro-controllers or processors, 50 more complex

Electronic Control Units (ECU). In general terms, we

will talk about processing units (PU) distributed in the

vehicle. Two representations co-exist for the grouping

of these units in modern vehicles.

• Feature groups: the vehicle is composed of Do-

main Controller Units (DCU) with similar func-

tionalities (ex: ADAS, Chassis, Body, etc.). This

simpliﬁes the manufacture and design of cars.

• Physical location: functionalities from the same

location area are grouped together to form a Zone

Controller Unit (ZCU) (ex: front left and right,

rear left and right, center, etc.). The goal is to

reduce wiring in cars.

In all cases, the DCUs and ZCUs are in the

vehicle-speciﬁc area managed privately by the Gate-

way. The role of the gateway is to isolate vehicle

control from external access to information. Thus the

blocks of communication (Inter-Vehicular, Vehicule-

to-Road, Infotainment) will have access to the Telem-

atic Control Unit (TCU) to communicate with the en-

vironment without being able to inﬂuence the safety

and security of the vehicle. The communication be-

tween the different blocks (DCU and ZCU) are made

by an Ethernet link in order to gain speed and band-

width. Figure 2 shows the two architectures (Feature

Group with DCU or Physical localization with ZCU)

in a modern vehicle.

Number of processing units (PU) is more and

more increasing in the vehicle and will continue to

increase in the future. These PUs will also communi-

cate together inside the vehicle and in its surrounding.

It is therefore necessary to propose a new approach

to optimize this number of PUs and their workloads.

Our approach is to be able to share our local comput-

ing resources in order to add new functionalities to

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

186

Figure 1: Illustration of a scenario with modern vehicle interactions.

the vehicle without having to redeploy PUs in DCUs

or ZCUs. The use of edge computing is a new method

to perform new tasks. In case you want to keep the lo-

cal computing capabilities, it is possible to maintain a

link to the cloud. This way of thinking allows us to

work independently the availability of resources and

thus make task delegation to other environments.

In the next section, we present these infrastruc-

tures and detail how they cope with EdgeAgent

model.

3 A MULTIAGENT APPROACH

BASED ON EDGE AGENTS

3.1 Motivation for a Multi-Agent

Approach

The motivation is the design of the future electronics

platform enabling to compose the capacities of dif-

ferent resources (PUs) into services making sense for

vehicle designers and users. Such platform requires

to meet different challenges:

• discoverability (C1): allow to discover heteroge-

neous resources, to be able to plug and unplug re-

sources to the platform;

• connectivity (C2): take into account several

communication models (request/response, event-

based, publish/subscribe, etc.) in order to allow

applications to interact with various resources, as

well as support connectivity disruptions for mo-

bile wireless connected resources;

• reactivity (C3): adapt its structure and behavior

to its environment and any potential changes at

runtime;

• safety (C4): be reliable and secure so that re-

sources and applications are harmless and avoid

privacy issues;

• interoperability (C5): allow any applications to

run across heterogeneous resources, so that users

can seamlessly interact with resources;

• delegation (C6): identify the most suitable loca-

tion to execute each code module and deploy these

modules on the resources processing unit or on

any external infrastructure (V2V, V2I, V2R), in-

stead of completely delegating computation tasks

to cloud-based infrastructures;

• scalability (C7): cope with high numbers of re-

sources, heavy calculation processes and/or high

quantities of data;

• collaboration (C8): allow a set of resources to

exhibit a collective behavior to achieve complex

functionalities;

• usability (C9): provide high-level services, so that

applications match vehicle-users’needs.

These constraints require decoupling decision-

making as much as possible the nodes that make up

the system. In other words, this point militates in

favour of giving them autonomous decision-making.

Pooling of Heterogeneous Computing Resources: A Novel Approach based on Multi-Edge-Agent Concept

187

Figure 2: Modern Vehicular Architectures with ECU repartition, Left: Feature groups, Right: Physical localisation.

The corollary is that the overall decision-making

process of the system is decentralized. The cloud-

based model actually used for vehicle electronics,

Figure 3 (Left) cannot cope to the previously pre-

sented challenges as resources are centralized. It

is necessary for these resources to cooperate and

theses resources do not need to have all knowledge

and skills to meet their individual (local level) and

collective (global system level) objectives. Putting

in cooperation autonomous agent systems is at the

heart of multiagent paradigm. In our context, Edge

computing can leverage computing resources that

cannot be all connected, as depicted in Figure 3

(Right).

3.2 Proposed Approach

In the vehicle approach, the execution of algorithms

on electronic vehicle must consider:

• Algorithms that can be deployed in the cloud for

execution,

• Algorithms that cannot be deployed in the cloud

and must be executed inside the vehicle,

• Algorithms and tasks that can be executed on any

ZCU or DCUs as long as the target PUs contains

the code/architecture,

• Algorithms and tasks that must be executed on a

speciﬁc ZCU or DCU for safety, security reasons

or for any other hardware constraints.

Sharing resources for future electronic vehicle

must consider that each algorithm may have some ex-

ecution and allocation constraints and the electronic

platform must consider all of them. Resources shar-

ing requires a model to supervise all resources, evalu-

ate the workloads and allocate the functions according

to the available resources. The proposed model is an

EdgeAgent model with three types of EdgeAgent, as

depicted in Figure 4:

• EdgeAgent Mediator: receives all requirements

and looks for the appropriate and available re-

sources in each ZCU and DCU to negotiate which

resources will be used,

• EdgeAgent Allocator: knows the states of each

PUs and allocate the tasks,

• EdgeAgent Processor: supervises the execution of

the functions on the target PU.

In this model, the EdgeAgent Mediator has a global

overview of the state and availability of each re-

source at any time. The EdgeAgent Mediator al-

locates functions to resources after EdgeAgent Al-

locator exchanges. For example, when the park-

ing assistance system is on, the associated algorithm

must be executed inside the vehicle on any resources.

The EdgeAgent Mediator is looking for available re-

sources and requests the EdgeAgent Allocators to

know what resources are available. The EdgeAgent

Mediator decides for example as resources in DCU1

will be used and the EdgeAgent Allocator associated

to DCU allocates the functions to DCU1 resources.

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

188

Figure 3: Vehicule evolution with the Edge Computing.

The EdgeAgent Allocator has a constant and precise

view of the state of the resources it is in charge.

The EdgeAgent Mediator has a global view of all

resources of the system whereas the EdgeAgent Al-

locator knows precisely the states of the associated

resources. The EdgeAgent Allocators communicate

with the EdgeAgent Mediator so it can decide how

and where to execute the functions. The role of the

EdgeAgent Processor is to supervise the execution of

the functions after deployment by the EdgeAgent Me-

diator and Allocator. These three types of EdgeAgent

will be put in the Edge to manage resources accord-

ing to services, algorithms and hardware and software

requirements. The number and localization of these

Agents depend on the electronics systems and their

role inside the Edge. First assumption can be done:

• The EdgeAgent Mediator has a global overview of

resources and zones and should be in the gateway

level,

• The EdgeAgent Allocator has a precise overview

of the states of its resources and can be in the gate-

way level or in the zone level,

• Several EdgeAgent Allocator exchange with an

EdgeAgent Mediator,

• EdgeAgent Allocators communicate to

EdgeAgent Processors,

• The EdgeAgent Processor should be near re-

sources, the closeness depending on the PUs man-

agement,

• EdgeAgent Allocator makes the link between

EdgeAgent Mediator and EdgeAgent Processor.

Figure 4: EdgeAgent model.

4 SYSTEM ARCHITECTURE

Embedded systems (ES) are deﬁned as information

processing systems integrated into dedicated products

(Marwedel, 2018). In our context, ES contains PUs

inside the vehicle and PUs outside the vehicle. The

purpose of ES is to respond autonomously (in cal-

culation, energy and memory) to a speciﬁc services.

Lee (Lee, 2007) advances the notion of Cyber Phys-

ical Systems (CPS) and deﬁnes it as an embedded

system to which is added the ability to capture in-

formation and/or act on its external environment. As

CPSs are now able to communicate their results to

each other, they become connected objects (Cervantes

et al., 2018). We identify three types of physical ob-

jects:

• Complex Objects: These objects provide software

services and dedicated communications that of-

fers service interfaces. It is then often trivial to

link these objects together or with other software

services.

Pooling of Heterogeneous Computing Resources: A Novel Approach based on Multi-Edge-Agent Concept

189

• Lightweight Objects: These objects cannot embed

servers due to restricted computing capacity but it

is often easy to link them to proxies. A proxy can

embed a Web server. The (object, proxy) couple

can be seen as a complex object that is physically

distributed.

• Bare Objects : These objects are passive objects

that can be detected. Passive objects receive data

When such an object is in the range of a RFID

reader, the reader receives a byte array. A logical

link can then be established between the physical

object and the byte array.

We propose two different types of agent archi-

tecture to embody the EdgeAgent: avatars will

allow the most powerful implementation (to ad-

dress strong requirements Ci) while IoT-A agents

will be the most economical in terms of en-

ergy/memory/CPU/bandwith consumption. An IoT-A

agent system can be abstracted by an avatar agent.

4.1 IoT-a Model

In previous works (Carlier and Renault, 2016; Re-

nault and Carlier, 2016), we propose the concept of

IoT-a for Internet of Things-agent. Objects are con-

nected and interact on the basis of a common lan-

guage. The diversity of architectures requires an

agent integration model capable of adapting to differ-

ent hardware levels.

According to the IoT-a model (Figure 5), we pro-

pose four main detailed conﬁgurations for the imple-

mentation of agents within an IoT or PU. These con-

ﬁgurations, respecting the constraints Ci (Ref. 3.1),

can be combined because they are independent. The

more complex an IoT or PU is, the more it can inte-

grate different agent conﬁgurations.

The conﬁguration 1 proposes the integration of an

agent at the hardware level. This ﬁrst conﬁguration is

applicable to connected objects that can be based on a

hardware architecture such as microcontrollers or an

ASIC (Skhiri et al., 2017). The component integrates

a material agent into the silicon and becomes an addi-

tional and autonomous function.

In the conﬁguration 2 an agent is present in addi-

tion to the global software system (e.g. operating sys-

tem). From this conﬁguration, it is assumed that the

system has sufﬁcient hardware resources to host an

operating system. This second conﬁguration can be

implemented on IoTs based on architectures such as

ARM, PowerPC or x86 (STMicroelectronics, Broad-

com, Intel, etc.). This is the ﬁrst all-software conﬁg-

uration but it is as close as possible to the hardware

and does not suffer the latency of an operating sys-

tem. The execution of agents has the possibility to be

CPSConfiguration2

EmbeddedSystem PhysicsAgent(s)

CPSConfiguration3

EmbeddedSystem PhysicsAgent(s)

CPSConfiguration1

EmbeddedSystem Physics Agent(s)

CPSConfiguration4

EmbeddedSystem PhysicsMAS

IoTaModel

Figure 5: IoT-a traditional model.

real time and/or secure.

The conﬁguration 3 allows the integration of one

or more agents into the software system. Agents are

present either in the software kernel to take into ac-

count low-level or real-time events, or in the user

space to respond to more complex problems that can

be multitasking. These agents, like those mentioned

in the ﬁrst two conﬁgurations, are autonomous and

require a multi-agent platform to exchange with other

agents present on different connected objects.

Finally, conﬁguration 4 proposes that the PU host

a complete multi-agent platform. The agents present

in the object can interact autonomously and can be in

large numbers.

The platform serves as a relay for agents and/or

MASs distributed on other types of hardware conﬁg-

uration (or hybrid conﬁguration) or other connected

objects in its network. This conﬁguration requires a

Processing Unit with sufﬁcient hardware resources to

run multiple agents and support different communica-

tion protocols at different hardware levels.

4.2 Avatar Model

An avatar is a virtual representation on the Cloud ex-

tending objects (Jamont and Occello, 2015; Jamont

et al., 2014; Mrissa et al., 2015) (Figure 6). Build-

ing this type of platform generally relies on proxy (a

projection of a physical object into the Web). Con-

cretely, it is a Web intermediary for requests from

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

190

clients seeking resources from other objects. Avatars

are not simple proxies. An avatar is an autonomous

entity (i.e. an agent). The increase of its knowledge

and its skills comes from (1) the Web which is the

avatar environment (so an avatar can access to the

Web of data and Web Service) and (2) others avatars.

Through their avatars, Cyber Physical Systems can be

in interaction and particularly in cooperation.

CyberPhysicalSystem(CPS)

EmbeddedSystem Physics

AvatarModel

Avatar

Avatar Avatar

CyberPhysicalSystem(CPS)

EmbeddedSystem Physics

Figure 6: Avatar model.

Some components of the avatar architecture are

dedicated to thing control and others implement the

autonomous, self-adaptive and collaborative behavior

of avatars. The physical setup is decoupled from its

logical architecture: an avatar can dynamically adapt.

The avatar components are divided into 8 functional

modules:

• the Core Module includes components that are

used in several steps of the avatar lifecycle. Each

avatar embeds a Reasoner, used by other com-

ponents to process semantic information pertain-

ing on the capabilities, functionalities and context.

So is the Local Cache, that stores semantic infor-

mation from diverse sources (thing, repositories,

external context) and reﬂects the current state of

the avatar. In particular, the cache loads concepts

from the semantic repositories, in order to make

them available to other modules through the rea-

soner. This module is essential to address the mul-

tiple concerns targeted by the application through

the avatar, while avoiding allocating unnecessary

resources. It participates in addressing most of the

requirements, and especially (C6).

• the Interoperability module provides the other

avatar modules with a uniform interface to inter-

act with the resources it is attached to (C1, C5).

This interface consists of a set of capabilities that

represent the thing API. It loads drivers from a

platform repository and uses them to identify the

communication schemes understood by the thing;

eventually, it uploads onto the thing the appropri-

ate conﬁguration.

• the Filtering module restricts functionality expo-

sition and data exchanges according to privacy or

security issues, some functionalities should not be

achieved by the avatar, they will be ﬁltered by

the Privacy manager. The Context Manager has

a more complex role.

• the Communication module ensures reliable com-

munication with the resources. It selects the ap-

propriate network interface and protocols accord-

ing to communication purposes and performance

needs (C4).

• the Web service module allows avatars to com-

municate with other avatars and with the external

world.

• the Local Functionality module handles high-

level functionalities achievable using the resource

capabilities (C9). It relies on semantic tech-

nologies to map the resource layer (capabilities)

with the application layer (functionalities) in a

declarative and loosely coupled manner, ensur-

ing application interoperability with various re-

sources (Mrissa et al., 2014) (C5).

• the Collaboration module handles functionalities

that require collaboration between several avatars

(Cervantes et al., 2018) (C8).

• the WoT Application module provides and con-

trols ”Web of Things (WoT) application contain-

ers” that execute code modules implementing the

different aspects of a WoT application (C9). Such

containers can be replicated on the resource, on

the gateway and on the cloud infrastructure thanks

to the deployment manager, so that modules are

executed on the appropriate location (C6).

5 CONCLUSION

Through this article, we provide a new approach

(EdgeAgent) of allocating task (Inguere et al., 2016)

for PUs in a modern vehicle. Contrarily to our both

separate initial model (IoT-a and Avatar), we pro-

pose a better ﬂexibility to manage a computational

resources. Now, depending on the complexity of the

PU, we can choose IoT-a model for objects with com-

putation resources or Avatar model for simple objects.

In the vehicle, the minimization of cables leads the

OEM to group the PUs by local area (ZCU) and not by

functionality category (DCU). ZCUs are connected

Pooling of Heterogeneous Computing Resources: A Novel Approach based on Multi-Edge-Agent Concept

191

by Ethernet cable to the gateway to increase the trans-

fer rate and reactivity. We can pre-process data locally

and provide new functionalities for data manipulation

using the edge computing principle. In the Figure 3,

the network approach is migrating from a pyramidal

to a cubic architecture. The introduction of the con-

cept of edge computing leads us to take the lead in

delegating tasks locally in the vehicle. The generic

tasks can now be executed on a different PU than the

one assigned by default. In the event that the func-

tionality cannot be achieved locally, we send the data

to the cloud for cluster server processing.

Following of our work, we will investigate the

possibility to extend our negotiation procedure to

other cubic edge, allowing by the way a resource

sharing between different hardware units. The STMi-

croelectronics also produces vehicular embedded sys-

tems. Later, we wish to distribute our agents on these

various units to delegate tasks between these different

resources (to vehicle, to road, to smart city).

REFERENCES

Carlier, F. and Renault, V. (2016). Iot-a, embedded agents

for smart internet of things: Application on a display

wall. In 2016 IEEE/WIC/ACM Int Conf. on Web Intel-

ligence, The First Int. Work. on the Internet of Agents,

pages 80–83. IEEE Computer Society.

Cervantes, F., Ramos, F., Guti

errez, L., Occello, M., and Ja-

mont, J. (2018). A new approach for the composition

of adaptive pervasive systems. IEEE Systems Journal,

12(2):1709–1721.

Inguere, T., Carlier, F., and Renault, V. (2016). Flexible

image processing in embedded systems using multi-

agents systems. In 14th IFAC/IEEE Int. Conf. on Pro-

grammable Devices and Embedded Systems (PDeS

2016), pages 164–169.

Jamont, J., M

edini, L., and Mrissa, M. (2014). A web-based

agent-oriented approach to address heterogeneity in

cooperative embedded systems. In Int. Conf. on Prac-

tical Applications of Agents and Multi-Agent Systems,

pages 45–52.

Jamont, J. and Occello, M. (2015). Meeting the chal-

lenges of decentralised embedded applications using

multi-agent systems. International Journal of Agent-

Oriented Software Engineering, 5(1):22–68.

Lee, E. A. (2007). Computing foundations and practice for

cyber-physical systems: A preliminary report. Techni-

cal Report UCB/EECS-2007-72, EECS Department,

University of California, Berkeley.

Marwedel, P. (2018). Embedded System Design: Embedded

Systems Foundations of Cyber-Physical Systems and

the Internet of Things. Springer Publishing Company,

Incorporated, 3rd edition.

Mrissa, M., M

edini, L., and Jamont, J. (2014). Semantic

discovery and invocation of functionalities for the web

of things. In IEEE int. conf. on enabling technologies:

infrastructure for collaborative enterprises.

Mrissa, M., M

edini, L., Jamont, J., Sommer, N. L., and

Laplace, J. (2015). An avatar architecture for the web

of things. IEEE Internet Computing, 19(2):30–38.

Renault, V. and Carlier, F. (2016). Triskell3S, une plate-

forme embarqu

ee multi-agents pour les IoT-a. In

Journ

ees Francophones sur les Syst

emes Multi-Agents

(JFSMA 2016), pages 181–190.

SA, R. (2019). Automotive System-on-Chip (SoC).

https://www.renesas.com/us/en/solutions/automotive/

soc.html.

Skhiri, R., Fresse, V., Jamont, J., and Suffran, B. (2017).

Challenges of virtualization fpga in a cloud context.

IEEE Int. Conf. on Computational Intelligence and

Virtual Environments for Measurement Systems and

Applications.

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

192