On Verify and Validate a Next Generation Automotive Communication

Network

Sebastian Brunthaler, Thomas Waas and Markus Kucera

OTH Regensburg, Regensburg, Germany

Keywords:

Automotive, Ethernet, In-car, Vehicle Communications, Vehicle Networks, Car-to-Car, Autonomous Driving.

Abstract:

As a result of the enormous growth in data trafﬁc for autonomous driving, the conventional in-vehicle network

is no longer sufﬁcient and requires new types of network concepts in a vehicle. This part of the automobile

is known as the next generation communication network. Since the new car-systems can be extended by

various services at any time, the network must adapt dynamically to new requirements wherever possible.

For example, data ﬂow must be conﬁgured dynamically between new services. Also data rates will be much

higher in the future than today. This is one of the main reasons why we need to search for new technologies

for data transfer in vehicles. This is based on an in-vehicle ethernet network. The process of conﬁguring

networks automatically has been discussed several times in recent years. One of the next steps is verifying and

validating the automatic conﬁguration process during the development of the new communication network.

This research paper identiﬁes several ways to ensure the automatically generated network conﬁguration leads

to a secure system. To achieve that, other parts of the company’s enterprise IT architecture and network

technologies, the conventional vehicle network and other options for veriﬁcation and validation are analysed.

1 INTRODUCTION

With the introduction of autonomous driving in road

trafﬁc, vehicles must be able to process signiﬁcantly

more data than before. For example a few years ago,

a car used to have one or two sensors, like cam-

eras, which used to transmit data through the system.

In the future, several cameras are expected to pro-

cess high-resolution data by self-learning ADAS (Ad-

vanced Driver-Assistance Systems) and autonomous

driving systems. Also, the resolution of images is

constantly increasing as the quality of images in-

creases. All these data has to be transmitted efﬁciently

via the new network and forwarded to their destina-

tion in real time, if required. This is necessary be-

cause a vehicle must be able to classify objects and

people within milliseconds. As an example, this is a

way to avoid accidents caused by incorrectly detected

elements. Therefore, this will be even more difﬁcult

in the future since, according to a prediction, more

than 70% of the world’s population is going to live

in urban areas by 2050. Hence, the conurbations cre-

ate complex driving situations for autonomous driv-

ing due to an increasing number of trafﬁc. It presents

a new dimension of inﬂuences and their complexity

OTH Regensburg, Continental Automotive GmbH

the automobile will have to cope with in the future.

The current vehicle network is not designed for the

enormously increasing requirements. Rigid bus sys-

tems such as CAN

, LIN

and FlexRay

are no longer

able to transmit the increased data volumes reliably

and in the time required. Additionally, it is impor-

tant to switch to a new vehicle network that has the

functionality to respond to dynamic changes in the

communications environment. For this, the Ethernet

technology would be chosen. However, this is not

going to replace the bus systems completely. The

main application area will be handling the commu-

nication between the central part of the network and

the connection of sensors, for instance, with high data

throughput. For illustration, ﬁgure 1 shows the evolu-

tion from a currently rigid network to a server archi-

tecture. In traditional architecture, each computing

unit is already conﬁgured statically in the beginning

and usually remains consistent. In a domain archi-

tecture on the other hand, these computing units are

usually consistent connected to each other with so-

called servers. Thus, they can be conﬁgured freely

and extended in their functionality. The next step is

https://ieeexplore.ieee.org/document/4678912

https://ieeexplore.ieee.org/document/1286317

https://ieeexplore.ieee.org/document/4677484

Brunthaler, S., Waas, T. and Kucera, M.

On Verify and Validate a Next Generation Automotive Communication Networka.

DOI: 10.5220/0008191601210127

In Proceedings of the 9th International Conference on Pervasive and Embedded Computing and Communication Systems (PECCS 2019), pages 121-127

ISBN: 978-989-758-385-8

121

a zone architecture, containing a central network of

servers. Sensors and actuators are connected to the

network via so-called zone ECUs. These in turn are

connected to the central computing units like servers,

which ultimately process the data. The ﬁnal state of

in vehicle network is nearly the same as the zone ar-

chitecture. To the central powerful server units, hard-

ware could be added and associated services runs on

one of the server units. Unlike the zone architecture,

the zone controllers are no longer required. The last

two expansion stages of the E/E architecture (Electri-

cal/Electronic Architecture) enable a modular expan-

sion of a vehicle with various services and hardware

through Plug&Play. This is a key aspect in the de-

velopment of a next generation communication net-

work. Vehicles are expected to be more personalized

in the future resulting in a broad spectrum of conﬁg-

uration options. Therefore, variety of combinations

requires the automatic conﬁguration of a network to

meet modularity requirements.(Carlson et al., 2019)

Due to the modularity of the system, current

projects such as the A3F project which is explained

in the section 2, aim at a service-oriented network

architecture. This means, applications are supposed

to be installed on a vehicle without having to physi-

cally visit a service point or the manufacturer of the

vehicle. In the future, this will take place through a

so-called App Store on the vehicle. Similar to smart-

phones, this includes a pool of applications to extend

the functionality of a car. The ability of vehicle hard-

ware extension through Plug&Play also implicates the

need of a network reconﬁguration from a single unit

accessible to all components within the system. In or-

der to fully integrate and support the hardware func-

tionality into the new network from a software per-

spective, data streams, port rules and additional ser-

vices must be conﬁgured and provided for the de-

sired functionality. The A3F project follows the con-

cept of software-deﬁned networking, similar to what

is known from software-deﬁned networks

(SDN) or

Software Oriented Architecture

(SOA). This are con-

cepts about building a service-oriented architecture

managed from a central location. This principle can

be applied to the desired software extension of the

system. However, this approach also involves risks.

The number of different conﬁgurations possible in the

system increases due to software extensions and dif-

ferent applications. For example, 10 services were

available to extend a system with 5 server units, there

were already 1001 possible combinations.

(n + m − 1)!

((n − 1)! ∗ m!)

(5 + 10 − 1)!

((5 − 1)! ∗ 10!)

= 1001

https://ieeexplore.ieee.org/document/6994333

https://ieeexplore.ieee.org/document/4026892

Since far more than these are planned for the future,

system conﬁguration can no longer be done for each

service individually evaluated and checked for possi-

ble errors in the end. Using SDN’s approach, conﬁg-

uration can be done from at least one central location.

As of now, there are several approaches to ensure a

veriﬁcation and validation process, but no practicable

solution for such complexity.

Another problem is represented by technologies

like CAN, LIN and FlexRay mentioned earlier in this

paper. In the future, these technologies will reach

their limits in an attempt to meet the requirements

as described for a new vehicle network. The data

to be sent can raise up to several gigabit per second

and must be sent in real time from a source Elec-

tronic Control Unit (ECU) to the destination ECU in

a system. For communication within the car, there-

fore it is necessary to use a modern medium. Since

2010, several major automotive manufacturers have

been working on integrating Ethernet into modern au-

tomotive architectures. However, Ethernet should not

completely replace all bus systems but rather comple-

ment them in order to transfer large amounts of data

between the devices as efﬁciently as possible. But not

only the automobile manufacturers have researched

for the integration of Ethernet, also several universi-

ties and key players in the global automotive industry,

such as Continental, Bosch and Vector, are convinced

of the necessity of Ethernet in the automobile (Stein-

bach et al., 2011)(Bello, 2011)(Eisele, 2018).

2 RELATED WORK

Over the last two years, the A3F research group men-

tioned in section I has developed a network man-

agement system which independently of components

conﬁgures a vehicle network. The project is a cooper-

ation between Continental Automotive GmbH and the

University OTH Regensburg. The research group de-

cided to deﬁne three expansion stages for in-vehicle

networks in terms of autonomous driving. The last

two states are called Next Generation Networks, pos-

sible network concepts are displayed in ﬁgure 1 on

timeline starting in the year 2025.

• The ﬁrst stage is to conﬁgure a network at the end

of the manufacturing process line. This represents

the today standard in automotive manufacturing.

• Secondly, the vehicle shall be reconﬁgured during

functionalities have been added. In this extension

the automatic process is used only if the vehicle

is in a safe state. Looking forward, there is still

a need for a precise deﬁnition of which state rep-

resents a safe state. An example for a save state

PECCS 2019 - 9th International Conference on Pervasive and Embedded Computing and Communication Systems

122

Figure 1: Future E/E Architecture (Carlson et al., 2019).

could be the idle state of a automobile, like park-

ing position. Though, this topic is not going to be

evaluated further in this paper.

• The ﬁnal expansion stage represents the future of

vehicle networks. Conﬁguration can be carried

out at any time. Thus, the functionality of a ve-

hicle can be extended at any time. A conceivable

scenario would be a new conﬁguration already

created and loaded in background in parallel to the

current conﬁguration. So, the new conﬁguration is

adopted into the network and its components but

only approved after successful parallel operation.

However, this requires more memory space and

computing performance in the components.

Currently the project focuses on stage 2 where

the vehicle has to reconﬁgure itself after changes in

the system feature functionalities by adding a service

or hardware. Figure 2 shows the concept of a man-

agement system which conﬁgured the network from

a central unit in the system. The central icon on

the illustration represents the network manager which

is able to use external input such as network topol-

ogy, message and service parameter from a manifest

into a new conﬁguration for the corresponding vehi-

cle network. The automatically generated conﬁgura-

tion should provide usage independent from the vari-

ous communication network topologies, so that man-

ual intervention is no longer necessary. The develop-

ment of the central network management for the sys-

tem was one of the A3F project outcomes. A consid-

erable part of the network manager implementation

is documented in two theses at the University Of Ap-

plied Sciences in Regensburg and can be consulted for

more detailed information (Brunthaler, 2018)(Urban,

2018).

Figure 2: Central Networkmanager.

As mentioned earlier, work has been carried out

in recent years on the automated conﬁguration of a

vehicle network using new vehicle components like

servers. By means of a demonstrator structure a simu-

lation can be realized. This structure has already been

implemented in the last few months. In the labora-

tory setup, a huge part of the network can be extended

and reconﬁgured with a variety of services without

the need of external intervention. To underline this,

some examples are the conﬁguration of data streams

and port rules at the respective switches or terminals,

such as an ECU or sensor, as well as the provision of

new services in the system. The next step to achieve

the target of this project is to develop a process to ver-

ify and validate the automatically generated network

conﬁguration. To evaluate the process of automati-

cally creating the conﬁguration of a vehicle network,

different approaches can be used for. These are ex-

amined for their feasibility and effort. The following

table 1 shows the investigated topics.

Table 1: Concepts for veriﬁcation and validation.

Technology Section Source

Independent Veriﬁcation and Validation 2.1 (Open Alliance, 2017)(techopedia, 2019)

Code Validation concepts 2.2 IEEE(IEEE, 2012)(IEEEa, 2017)

System life cycle Processes 2.2 ISO(ISO, 2015)

Classiﬁcation in test category 2.3 University

of Prague(Sobotka, 2017)

Automatic and Simulation In-the-loop Test 2.4 (Bock et al., 2008)

Mathematical proof of algorithm 2.5 (Ziegenbalg et al., 2016)

In the following sections, the work on the topics

listed in table 1 are explained in further detail. Only

the points for which broad searches were necessary

are listed.

2.1 Independent Veriﬁcation and

Validation

Independent Veriﬁcation And Validation (IV&V)

fully incorporates the concept of Veriﬁcation And

Validation (V&V). The difference to classic V&V is

that IV&V is performed by a third party company not

involved in development. In this way, software and

hardware can be tested by third parties. The main ad-

vantage of independent testing is the accurate veriﬁ-

cation of the opportunity to accurately verify the spec-

On Verify and Validate a Next Generation Automotive Communication Networka

123

iﬁcations and functionality of the product to be tested

the accurate veriﬁcation of the opportunity to accu-

rately verify the.(techopedia, 2019)(IEEEb, 2017)

In the A3F project Independent Software Veriﬁca-

tion And Validation (ISV&V) which is part of IV&V

plays a major role. This is usually done according

to previously given methods. In this case, the IV&V

concept could look like this:

• ISV&V Concept Planning

– System Criticality Analysis

– Identiﬁcation of Critical Components

– Selection of suitable methods and audit tools

• Speciﬁcation of Requirements

– Veriﬁcation for: Completeness,

Correctness, Testability

• Veriﬁcation of the Design

– Veriﬁcation of design and conformity between

software requirements and interfaces

– Feasibility check, as well as internal and

external consistency

• Veriﬁcation of the Code

– Analysis of code metrics

– Compliance with code guidelines and

conformity testing

– Completeness, Correctness, Consistency

• Validation

– Identiﬁcation of faulty or error-prone

components/functions

– Compliance with software and system require-

ments

– Black- and white box testing

Within the A3F project and the automotive indus-

try, one of the best known institutions for indepen-

dent testing is the Open Alliance with their deﬁnition

of the TC1 to TC14 Technical Comittees. The Open

Alliance is a group of several companies interested

in the standardization and testing Ethernet technolo-

gie in modern vehicle networks. Therefore, new test

speciﬁcations are constantly being developed to en-

sure uniform protection of the new technology. These

tests are also deﬁned by test models such as IV&V.

One of the speciﬁcations is the TC8. This document

contains several tests for electronic vehicle controls

which must be passed prior to installing the compo-

nents on the vehicle. The tests in TC8 are located on

the ISO/OSI layers one, two and three, known as the

data link and network layer. The tests are usually done

by independent test institutes according to the speci-

ﬁcations of the Open Alliance.(Open Alliance, 2017)

2.2 System Life Cycle Processes and

Code Validation

The concept of life cycle process is known from other

IT areas and software development. In general, this

demonstrates the applications V-cycle principle which

is shown in ﬁgure 3. This principle is based on

the constant monitoring of individual development

stages. In contrast to TC8, this is not only a ﬁnal

check but a permanent one. This type of veriﬁcation

and validation should be saved for the development

process of the next generation vehicle network, as it

allows an early detection of errors and malfunctions in

the system or software. Also, processes for code val-

idation should be integrated at this point. That way,

uniform standards can be guaranteed during develop-

ment. The recommended way of implementing this is

using of IEEE standardization (IEEE, 2012)(IEEEa,

2017), code guides and software patterns. The main

advantages of this are that errors can be found more

easily, as well as clearer and comprehensive code.

2.3 Deﬁne Classiﬁcation in Test

Categories

To ensure that the process of automated conﬁguration

creation delivers accurate results, not only the initial

generated conﬁguration, but also the algorithms have

to be tested on its own. To achieve this, an inven-

tory of the test metrics for this type of system must

be made. One possibility is the methods contained in

the publication to verify and validate distributed auto-

motive systems(Sobotka, 2017) released test concept

to deﬁne a classiﬁcation for the individual elements.

In Fig. 4 a model of the classiﬁcation is represented

graphically. Thus, the implementation and execution

of tests can be guaranteed for all components which

were generated during conﬁguration.

Figure 3: V-Cycle of development.

PECCS 2019 - 9th International Conference on Pervasive and Embedded Computing and Communication Systems

124

Figure 4: Classiﬁcation for testing (Sobotka, 2017).

2.4 Automatic and Simulation

In-the-loop Test

In order to cope with the growing complexity, the

process of veriﬁcation and validation must be auto-

mated to the extent possible. The concept Simulation

In-the-loop test is limited to the application layer in

the ISO/OSI

model, primarily. Firstly, simulations

and tests are performed for the individual services

to ensure they operate smoothly. This takes place

during development by testing the source code be-

fore it gets uploaded in the so-called appstore. In the

next step, automated tests are designed in the runtime

environment of an application. Here, the complex-

ity mentioned above plays a big role because not only

the system itself grows but also the simulations from

the in-the-loop tests quickly become very complex.

Therefore, they cannot be tested directly in the ve-

hicle in the required time due to the high number

of possible combinations of the various services al-

ready discussed. Hence, tests must be carried out

automatically in advance and their results must

be available in order to compare them with

the conﬁguration created. For this purpose,

test tools such as Jenkins

, Ranorex

, Gating

https://ieeexplore.ieee.org/document/1094702

https://jenkins.io/

https://www.ranorex.com

https://gatling.io/

and Tsung

can be used. These are well suited for

the development process of various applications. The

application level testing approach appears promising

as it is already used in related areas such as Internet of

Things (IoT)(Murad et al., 2018) and Cloud Comput-

ing. In Cloud Computing, validation is performed at

the level of cloud services, so every service is tested

before it is deployed on a system (Sehgal and Bhatth,

2018).

One way to check the conﬁguration is to transfer

an automatically generated conﬁguration of the vehi-

cle network to a powerful backend which is able to

run the tests or compare with existing results.This ap-

proach could be realized using Over-The-Air Tech-

nology (OTA), for instance. In case of a positive eval-

uation, the conﬁguration can be adopted in the net-

work. An example communication between vehicle

and backend is shown in ﬁgure 5. This procedure is

time-consuming and requires a powerful network and

backend, which is associated with high costs. In re-

cent times network expansions used to be a big topic.

The 5G technology mentioned here could provide the

bandwidth necessary for the network. This would en-

able the approach of transmission to a powerful back-

end, in general (Andrews et al., 2014).

2.5 Mathematical Proof of Algorithm

Under the assumption that a computing unit such as

an ECU is implemented correctly and provides cor-

rect results, it is still very difﬁcult to verify the ac-

curacy of the algorithm for automated conﬁguration

generation. Ideally, a theoretical proof for the cor-

rectness of this algorithm should be found. For this

purpose, each sub-function of the automatic conﬁg-

uration algorithm is checked separately. This proce-

dure is called a partial veriﬁcation of correctness. The

next step is to check the entire algorithm for absolute

correctness (Ziegenbalg et al., 2016). Since the full

complexity of the network management functionality

is not yet known, a mathematical proof approach will

be difﬁcult. Also disturbances by other network par-

ticipants are not yet excluded by a formal proof and

must be checked beforehand. Therefore, it is clear

that the mathematical proof is one of the most com-

plex operations for such an algorithm. One option

is the implementation of mathematical and software

checks to test the algorithm itself using the result as

a complete induction veriﬁcation of the functionality.

A second possibility is a comprehensive brute force

test of the network. This way, possible anomalies can

be found after a system reconﬁguration. This test ex-

amines a large number of cases in which errors can be

http://tsung.erlang-projects.org/

On Verify and Validate a Next Generation Automotive Communication Networka

125

Figure 5: Backend communication.

detected. Hence, the chance of detecting all errors is

high but there is no guarantee.

3 CHALLENGES OF TESTING

DYNAMIC NETWORKS

The greatest difﬁculty in testing the next generation

network lies in the variety of possible combinations

of the individual software and hardware components

that can be found in the system. Due to the modular

extension of a network, there are practically no limits

to the complexity of a system. This is a fundamen-

tal challenge for the approach of automated network

conﬁguration at a central point in the network. How-

ever, the real challenge for the future is the validation

and veriﬁcation of the created conﬁguration.

3.1 Closely Coupling among Software,

Hardware and Network

Due to the different dependencies between the indi-

vidual components, these must be solved ﬁrst in order

to run speciﬁc tests for application and device level in

the network. Further, before testing the functionality

of the overall system, the individual levels have to be

evaluated. Here, too, automation needs to be applied

to testing.

3.2 Communication Paths

As the network grows, so does the number of pos-

sible communication channels in the system through

which applications can exchange data. New account

points such as switches are emerging which need to be

conﬁgured to transfer data quickly and correctly. In

addition, mechanisms such as redundancy can create

complex problems for system veriﬁcation. Checking

all these paths and their devices is a difﬁcult task.

3.3 Automated Veriﬁcation and

Validation

Automation is one of the most important issues in the

veriﬁcation and validation of a new network. Only

by automating tests, it is possible to check the various

conﬁgurations. For this purpose, tools must be found

that not only test software automatically, but also ful-

ﬁll test requirements such as the IV&V described in

section 2.1. This will be most likely an extension of

an existing test tool or a combination of several.

3.4 Security

Protection against unauthorized and unwanted mod-

iﬁcation or manipulation of an automatically created

network conﬁguration also plays an important role in

veriﬁcation and validation. If a conﬁguration has been

unauthorizedly modiﬁed from outside this should also

be detected by software testing in the system. With

this, the system should be protected internally and

against external manipulation.

3.5 Safety

Not only security but also safety is an important as-

pect. In order to be able to determine exactly which

danger emanates from the new system, an assess-

ment must ﬁrst be made according to the ASIL lev-

els. These deﬁne the dangers for the environment of

the vehicle. In the paper Sicherheit von autonomem

Fahren the different driving situations are considered

on the basis of ASIL and grouped into the differ-

ent subclasses (Wirth and Reif, 2018). Based on

the levels, various safeguards must be created which

will also have an inﬂuence on the network, such as

redundant and real-time communication. The term

safety essentially contains two components, func-

tional safety and safety of the intended functionality

(SOTIF). Safety and security in combination are seen

as a unit who’s requirements needs to be met by the

sytem at all times and must be fulﬁlled by the sys-

tem.(Schnieder and Hosse, 2019)

4 PROMISING APPROACHES

All the approaches presented are important for veri-

ﬁcation and validation of the next generation vehicle

network. Nevertheless, in the research area of Group

A3F, a prioritisation has emerged which will be pur-

sued further in the coming months. Primarily, this

will be a combination of Independent Veriﬁcation and

Validation (IV&V) 2.1 and Software deﬁned Network

PECCS 2019 - 9th International Conference on Pervasive and Embedded Computing and Communication Systems

126

and Architecture. With service-oriented architecture

and testing, this forms a promising veriﬁcation and

validation approach.

5 WHERE TO NEXT

The next steps in this research project are the exten-

sion of the table to include concepts from other ar-

eas of corporate IT, as well as the detailed elaboration

of the concepts described in promising approaches 4

concepts. After the complete elaboration of the most

promising approaches, feasibility studies have to be

deployed. These have yet to be deﬁned and imple-

mented. It would be conceivable to do feasibility

studies on the existing A3F project demonstrator in

order to obtain well-founded test results. Currently,

the biggest problem with the system is the complex-

ity of the new vehicle network which will be difﬁcult

to estimate. One of the described process for testing

and designing the veriﬁcation and validation concept

is not sufﬁcient. Therefore, a combination of several

procedures must be put together to solve this problem.

REFERENCES

Ing. Jan Sobotka, Methods for Veriﬁcation and Validation

of Automotive Distributed Systems, Czech Technical

University in Prague, August 2017.

Till Steinbach; Franz Korf; Thomas C. Schmidt, Real-time

Ethernet for Automotive Applications: A Solution for

Future In-Car Networks, Hamburg University of Ap-

plied Sciences, Germany, IEEE 2011.

Lucia Lo Bello, The case for Ethernet in Automotive Com-

munications, University of Catania, Italy, 2011.

IEEE, Inc. Standard for System and Software Veriﬁcation

and Validation, IEEE 1012-2012, edition 2012.

IEEE, Inc. Standard for System, Software and Hardware

Veriﬁcation and Validation, IEEE 1012-2016, edition

2017.

IEEE, Applying Standard Independent Veriﬁcation and Val-

idation (IV&V) Techniques within an Agile Frame-

work: Is there a Compatibility Issue?, 2017 Annual

IEEE International Systems Conference (SysCon)

Open Alliance, OPEN Alliance Automotive Ethernet ECU

Test Speciﬁcation, Open Alliance, v2.0 edition 2017.

ISO, Systems and software engineering – System life cycle

processes, ISO/IEC/IEEE 15288, edition 2015.

Sebastian Brunthaler, Erweiterung eines Netzwerkmanager

zur automatischen Konﬁguration der sich im Fahrzeug

beﬁndenden Netzwerkger

ate anhand verschiedener

Applikationsparameter, OTH Regensburg, 2018.

Daniel Urban, Untersuchung von Methoden zur Ein-

bindung von virtuellen Umgebungen in ein zuk

unftiges

Ethernet-basiertes Fahrzeugnetzwerk, OTH Regens-

burg, 2018.

Jochen Ziegenbalg; Oliver Ziegenbalg; Bernd Ziegenbalg,

Korrektheit von Algorithmen Korrektheit von Com-

puterergebnissen, Algorithmen von Hammurapi bis

odel, 2016.

Johannes Eisele, Zwei Drittel der Weltbev

olkerung werden

2050 in St

adten leben, Zeit Online 2018.

Thomas Bock; Markus Maurer; Franciscus Meel; Thomas

uller, Vehicle in the Loop. In: ATZ Automobiltech Z

110 (1), S. 10–16. DOI: 10.1007/BF03221943.

G. Murad; A. Badarneh; A. Quscf; F. Almasalha, Software

Testing Techniques in IoT, S. 17-24. 2018 8th Interna-

tional Conference on Computer Science and Informa-

tion Technology (CSIT), Amman 2018

Dr. Lars Schnieder; Ren

e S. Hosse, Leitfaden Safety of the

Intended Functionality, Springer Vieweg, 2019

Techopedia, https://www.techopedia.com/deﬁnition/24836/

independent-veriﬁcation-and-validation–iv&v

Thomas Erl, Service-Oriented Architecture. Concepts,

Technology, and Design, Prentice Hall PTR, Upper

Saddle River 2004

Eike Bj

orn Schweißguth, Entwicklung und

Evaluierung eines SDN-gest

utzten echtzeitf

ahigen

Ger

atenetzwerkes, Springer Vieweg, 2016

Naresh Sehgal; Pramod Chandra P. Bhatth, Cloud Comput-

ing, Concepts and Practices, Springer International

Publishing, 2018

Patrick Wirth; Monika Ulrike Reif, Sicherheit von au-

tonomem Fahren, Winterthur : ZHAW Z

urcher

Hochschule f

ur Angewandte Wissenschaften, 2018

Steve Carlson; Christopher Mash; Christoph Wechsler;

Helge Zinner; Olaf Grau; Natalie Wienckowski, Au-

tomotive Ethernet: Beyond 10 Gb/s Electrical PHYs

call for interest, IEEE 802 LMSC March 2019 Ple-

nary meeting in Vancouver, BC, Canada, 2019

Jeffrey G. Andrews; Stefano Buzzi; Wan Choi; Stephen

V. Hanly; Angel Lozano; Anthony C. K. Soong;

Jianzhong C. Zhang, What Will 5G Be?, IEEE Journal

on Selected Areas in Communications (IEEE Journal

on Selected Areas in Communications), 2014

On Verify and Validate a Next Generation Automotive Communication Networka

127