1

Technical Article

August 2013

New Perspectives on Remaining Bus Simulation for Networks with SOME/IP

Taking the example of SOME/IP (Scalable Service-Oriented Middle-

ware on Ethernet / IP), this article shows how to implement a

remaining bus simulation [1] for dynamic, service-oriented IP net-

works (Figure 1). Afterwards, the aspects of media access, syn-

chronization and controlled stimulation [2] are discussed, and rec-

ommendations for the development system are derived from them.

Use of Service Protocols Based on the Example of SOME/IP

In the Ethernet and IP field, there are a tremendous number of

protocols to choose from, and one might think that protocols

already exist that could be used directly in all conceivable types of

applications. However, since networking in the vehicle does not

start at zero, certain specific requirements become immediately

apparent. For example, the protocols used must be incorporated

into existing systems. In particular, this relates to good integra-

tion in AUTOSAR and fast reaction times to keep delays short in

case of error. BMW AG has developed and specified SOME/IP, which

is an open protocol that fulfills automotive requirements. A SOME/

IP implementation is available from Vector for use in ECUs, includ-

ing a TCP/IP stack, Service Discovery and BroadR-Reach Ethernet

driver.

SOME/IP offers interfaces for service-oriented communication

(Figure 2). This distinguishes it from the pure signal-based com-

munication that is usual in CAN, for example. SOME/IP is roughly

subdivided into three areas: Service Discovery (SD), Remote Proce-

dure Call (RPC) and access to process data. The SD area lets ECUs

find services or offer their services in the network. The user utilizes

methods offered by SD via RPC (Figure 3, Part A). In addition, it

is possible to set up notifications for specific events (Figure 3,

Validating automotive IP network elements

Ethernet based on BroadR-Reach is already a reality in vehicles with camera applications, and it will reach other application areas as well. Specialized development tools even permit time-synchronous display of the communication of heterogeneous networks. To enable bandwidth efficiency, automotive IP networks – in contrast to static CAN communication – are set up in a dynamic and service-oriented way. Therefore, the development tools must also support service-oriented protocols such as SOME/IP.

2

Technical Article

August 2013

Part B). The application can use read and write functions to access

any specific process data (Figure 3, Part C). The goal of SOME/IP is

to optimally utilize available bandwidth to implement very flexible

communication. The communication and the signals are described

using FIBEX 4.1 or higher or AUTOSAR formats version 4.1 or

higher.

For the remaining bus simulation, SOME/IP serves as a complex

protocol and middleware with all of its degrees of freedom. To keep

user complexity as low as possible, the remaining bus simulation is

largely configured autonomously. This involves the use of stan-

dardized description formats such as FIBEX 4.1 or AUTOSAR. This

gives users direct access to the signals. However, manual overwrit-

ing of the configuration is desirable in executing tests, e.g. to pro-

voke error cases.

Flexible Network Access for the Test Tool

Implementing the complex task of a test tool – such as a remaining

bus simulation – as optimally as possible requires that the applica-

tion has flexible and high-performance access on the physical

medium (Figure 4, remaining bus simulation). Using this access,

the developer must be able to generate error cases (e.g. CRC

errors) on the network. If the primary focus is on analyzing a con-

nection between two nodes, special measures must be taken to

enable transparent, interference-free access. This is necessary,

because although Open Alliance BroadR-Reach (OABR) is logically a

bus system, electrically it is a point-to-point connection.

An obvious solution is to use an additional monitor port on the

switches used in the system. However, for cost reasons this cannot

always be done in the production version system [3]. Using what is

known as mirroring, the switch forwards all received packets to the

monitor port. One disadvantage of this solution is that the received

data packets do not have any common time reference – there are

no time stamps. For another, it is often the case that only valid

packets are forwarded to the monitor port, which makes error

analysis difficult.

Media access with little effect on the network under analysis is

provided by a so-called TAP (Test Access Point) [2]. Unlike a stan-

dard switch, this TAP makes it possible to transparently analyze an

Ethernet network without affecting the communication between

two nodes (Figure 4, flexible TAP). The TAP may be operated in

two different modes, depending on the following requirements:

> The purely passive operating mode guarantees short and con

stant latency time, but in this mode it is only possible to listen

on the medium.

> In the active mode, additional data may be injected into an

existing connection.

Fig ure 2 :SOME/IP offers an interface for calibration.

Fig ure 1 :Excerpt from a heterogeneous network architecture with Ethernet networks.

3

Technical Article

August 2013

The active connection cannot be made on the Physical Layer (OSI

Layer 1), however, because additional flow control is necessary.

Flow control is not available until Layer 2. Nonetheless, flow con-

trol cannot guarantee constant latency time.

Regardless of the method chosen, precise time stamps obtained

as close as possible to the Physical Layer are necessary for precise

analysis of the packet data. These time stamps must be synchro-

nized with other interfaces, because network analysis often focus-

es on more than just one Ethernet path as well as on other automo-

bile networks.

Choosing the Development Tool

Based on the above considerations, every developer should ask five

questions before choosing a development tool:

> Does the development system support service-oriented commu-

nication like SOME/IP?

> Does the development system provide logging and controlled

stimulation with and without protocol violation?

> Does the development system offer access to typical automotive

networks such as OABR, CAN, FlexRay and MOST?

> Can the interface be used flexibly as a TAP for mirroring and as a

converter and switch [2]?

> an the interface for supporting heterogeneous networks be

synchronized with all commonly used bus systems and IP

networks?

The development tool CANoe.IP supports all of these functions with

the VN5610 Ethernet/CAN interface from Vector. Therefore, it is

already being used at some automotive OEMs and suppliers.

Outlook

IP-based, service-oriented communication is making great strides

forward. After being used in camera applications, Ethernet will be

used in the infotainment area and then in other system domains,

e.g. as a backbone. For developers of vehicle networks, the signifi-

cance of multi-bus capability, remaining bus simulation and low-

level time stamps for all data packets continues to grow.

Translation of a German publication in Automobil Elektronik, 4/2013

All Figures: Vector Informatik GmbH

References:[1] Schnelle Wege zur Restbussimulation: Virtuelle Netzwerke ohne Pro grammier-Know-how erstellen (“Quick paths to the remaining bus sim ulation: Creating virtual networks without programming know-how”), Stefan Albrecht and Peter Decker, Automobil Elektronik 03/2012[2] Neue Werkzeuge für Automotive Ethernet (“New tools for automotive Ethernet”), Hans-Werner Schaal, Matthias Schwedt, Hanser automotive 3-4/2013[3] Herausforderungen von Ethernet-Debugging (“Challenges of Ethernet debugging”), Helge Zinner, www.elektroniknet.de, October 2012

Figure 4: The VN5610 interface is used in various application cases.

Fig ure 3 :SOME/IP offers various types of access such as RPC, notifications and read and write functions.

4

Technical Article

August 2013

Hans-Werner Schaal (Dipl.-Ing.)is Business Development Manager for the area of Ethernet, Car2x and open CAN proto-cols such as J1939 and ISOBUS at Vector Informatik GmbH.

Matthias Schwedt (Dipl.-Ing. (FH)) is FPGA developer for Ethernet, FlexRay and MOST150 network interfaces as well as over-all Project Leader for the VN56xx Ethernet network interface product line at Vector Informatik GmbH.

Peter Fellmeth (Dipl.-Ing. (FH)) is Group Leader and Product Manager at Vector Informatik GmbH. He is responsible for developing products and customer- specific projects in the Ethernet, J1939 and ISOBUS fields.

>> Contact information for all locations of the Vector Group: www.vector.com/contact