Cybersecurity in AUTOSAR

Encrypted comms

There are two purposes for cryptography in communication systems: authenticity and privacy.

Authenticity

The sender signs the data sent so the receiver can determine that the data is authentic and sent by the sender. Prevents man in the middle attacks.

Privacy

Data can be encrypted for privacy. Only the receiver can decode the data. Sender and receiver share a secret key (symmetric encryption) or it can be asymetric (public and private key).

AUTOSAR mechanisms

In AUTOSAR, there is SecOC for data authenticity.

Additionally, CRY, Cryptolib, Csm manage the security from MCAL to service layer. From the HSM (crypto co-processor) to the RTE.

More than AUTOSAR

IPsec for both authenticity and privacy at IP level. MACsec at MAC level. And TLS for V2G and secured on board HTTPS. As well as X.509 certificate exchange for authentication for software download and diagnostics.

All these mechanisms are currently integrated in todays vehicle architectures with Ethernet.

Stay tuned for next posts on  AUTOSAR cybersecurity and Ethernet.

More info: contact guru@autoethernet.com

AUTOSAR SomeIP and Service Discovery intro

Rationale

Automotive industry as a whole is changing fast due to modern times: electrical vehicle, autonomous driving, ADAS, conenectivity, etc.

Also, everthing around our every day lives is changing: the Internet of Things (IoT), Industry 4.0, big data, machine learning.

In general, we are building smarter and smarter machines everyday. Everything is connected to the Internet and appears to be intelligent.

The same happens to the cars. And this requires flexible vehicle architectures and powerful ECUs in terms of computing power.

These powerful ECUs need to exchange tons of information. And the best way to do so is through Ethernet starting at 100Mbps (and 1Gbps coming soon).

Powerful ECUs mean more costs in an industry in which efficiency is a religion. And not every carline will come with the top notch functionality: there is still room for cost effective cars not in the premium segment.

So, vehicle architectures need to be flexible. Reutilize as much as possible between carlines but at the same time wasting the less resources.

Therefore, having a smart and flexible way to deploy functionalities inside a vehicle architecture looks like a great idea. And this is what Service Discovery provides: the funcionalities inside the vehicle architecture are deployed as services in ECUs which provide them. Then we have the consumers or clients, other ECUs which look for these services they need and they try to find them in the network.

Adaptive AUTOSAR and Classic AUTOSAR

AUTOSAR software architecture, now it its 4.3 version, is renamed to “Classic” AUTOSAR. A new software architecture emerges: Adaptive AUTOSAR. Why?

New powerful ECUs are built with application microprocessors instead of microcontrollers. The complexity of the new applications require complex Operating Systems and software frameworks including Linux, Android and Hypervisors, among others. This is why the AUTOSAR consortium has developed the new software architecture, based in POSIX standards.

Matching all together. SomeIP to exchange data

With the new vehicle architectures, where Classic AUTOSAR and Adaptive AUTOSAR cohexist, and with tons of data to be exchanged, Ethernet is the predominant bus.

The protocol for exchanging data is SomeIP, which is just a serialization of data signals coming from the RTE into UDP PDUs. Serialization is done in the RTE, then data is transmited in BSW from LdCom to PDU Router, and then from Socket Adaptor to the TCP/IP stack.

What happens when the data to be transmited is too big for a single UDP packet (remember UDP payload up to 1472)? SomeIP TP (Transport Protocol) is added for this purpose.

The whole picture can be seen in the following image:

Stay tuned for new blog entries and remember that the Python libraries for testing purposes of DoIP and SomeIP / Service Discovery are coming soon to the download area.

Any doubts, you can write a comment.

Contact: guru@autoethernet.com

Your AUTOSAR partner.

 

 

 

 

DoIP in a nutshell

What’s it all about

Ethernet technology has been around in our lives for decades now. It’s fast, reliable, quite simple and completely standardized. Most important, there is so much knowledge and such a big industry that has been using and expanding Ethernet technology and its uses cases that nowadays it is really really mature and has been applied to so many different scenarios that almost anything can be achieved with this technology which is quite new to the automotive industry.

The basic scenario would be connecting an external tool like a tester to a car, but instead of using the earlier automotive-standard-for-everything, AKA CAN bus, using Ethernet instead. This means, just for the beginning, that almost any computer can be connected without the addition of expensive CAN boxes.

But Ethernet is so powerful and flexible, than many scenarios are possible, including the futuristic remote diagnostics and software update over the air, also known as SOTA or FOTA.

How it works

We are talking about Ethernet, because the Automotive Ethernet is the term always used when referring to the new technology applied to the automotive industry. But it’s also the whole TCP/IP stack ported to the cars.

We cannot continue here without introducing AUTOSAR, the automotive consortium for the standardization of an open software architecture for the vehicles.

AUTOSAR is just the one of the best things to happen to the industry ever. AUTOSAR software architecture is standard, open, efficient and very well documented. It promotes the collaboration between the parties in the automotive industry, which helps real standardization and enriches the ecosystem.

So, when AUTOSAR consortium decided to add Ethernet and the TCP/IP stack to the software architecture, motivated by the develpment of the new 100BaseT1 technology in the physical layer which allowed the usage of Ethernet in cars, this was a huge step and the AUTOSAR stack grew significantly. Let’s take a look at the AUTOSAR TCP/IP stack with DoIP:

The big box on the left is the TCP/IP stack coming from the telecom world. DoIP compoment is the box with the red stripes around. And one of the most important players and new software component added is in the middle between both: SoAd. The Socket Adaptor software component. This is a big one. It’s functionality can be summarized as taking the UDP messages or the TCP streams and putting this information into AUTOSAR PDUs. In AUTOSAR, we know about PDUs (note: do not confuse TCP/IP PDUs with AUTOSAR PDUs!!!). In AUTOSAR, we want to be as abstracted as possible from the TCP/IP world. And this is exactly what SoAd does.

Below the TCP/IP stack, there is the Ethernet Interface (EthIf), which is the abstraction layer for the Ethernet Driver MCAL specifics.

Stay tuned for next posts coming soon for DoIP protocol specifics!

Download link for the DoIP python precompiled library for testing purposes will be added soon!

Ask for the DoIP automotive embedded software implementation in C in the email below or in the contact form

guru@autoethernet.com

Your Automotive Ethernet partner

Powered by WordPress. Theme: Fino by: Design By freepsdworld.

Automotive Ethernet