SOME/IP Overview
HTML-код
- Опубликовано: 24 июл 2024
- In the fast-paced realm of automotive innovation, data transmission and complex communication systems are pivotal. Traditional methods have faced limitations, prompting the rise of service-oriented architectures as a solution. Join us in delving into the realm of SOME/IP (Scalable Service-Oriented Middleware over IP) and its role in fostering seamless communication within vehicles.
Unveiling SOME/IP:
Originally introduced by BMW in 2011, SOME/IP has garnered significant attention, particularly after its clear specification by AUTOSAR. This specification update brought about crucial enhancements, notably in Service Discovery, which empowers endpoints to seamlessly identify and utilize services offered by other ECUs within the network.
Pioneering the Future:
As the automotive landscape shifts towards zonal architectures and software-defined vehicles, the need for adaptable communication frameworks becomes paramount. Service-oriented architectures, empowered by SOME/IP, cater to this demand by facilitating dynamic service discovery, enabling efficient data flow, and supporting vital functionalities like Over-The-Air updates. Embrace the power of SOME/IP today to shape the vehicles of tomorrow.
Like us on Facebook: / intrepidcontrol
Follow us on LinkedIn: / intrepidcontrol
Follow us on Twitter: / intrepidcontrol
Follow us on Instagram: / intrepidcontrol
Website: www.intrepidcs.com/
Chapters:
00:00 - SOME/IP Overview
01:06 - Motivation for SOME/IP
02:09 - SDV/Zonal Architecture
02:57 - Example 1: Smart Phone Contact List
08:29 - Example 2: RADAR System
10:49 - Example 3: Mirror Service
12:09 - SOME/IP Specifications in AUTOSAR
18:09 - What is a Service
20:31 - SOME/IP Overview
22:17 - Types of Communication
24:51 - SOME/IP - IP Configuration
27:11 - SOME/IP Header Format
31:21 - Mirror Service in Detail
39:40 - SOME/IP - Payload/Transformer
41:46 - Serialization - Transformer Basics
43:43 - Serialization - Transformer with Tags
48:31 - Service Discovery - Sub/Pub
50:22 - Service Discovery - Message Flow
52:50 - Service Discovery - Message Structure 
Развлечения
thank you!
great talk, straight to the point, while also offering a real deep understanding of all necessary details. imho a perfect overview by all standards
This is awesome. What I have been trying to learn for months, I was able to grasp them in an hour. Thanks for this nice presentation.
Thank you, we will add more content like this in future
Good session, looking forward to more videos
Thank you.
Rather than good session, it is very very good session.
If possible, can you post the video/session on Some/Ip header where sir was explaining the Entry and Optional field. I'm very curious about dip dive there.
Thanks in Advance
Thank you, we will let him know.
In this SOA, what if the sensor modules are just raw data senders instead of service providers?
You can think of a sensor as a unit that can provide services. Usually, each format (raw form or sample rate) is its own service.
If the sensor modules do not have SOME/IP support built in, then in this case, they must send raw data over the network that the sensor supports - for example, CAN, FlexRay, Ethernet, etc.
For Etherent a simple UDP datagram can work.
@IntrepidControlSystems , many thanks!
this raw data in the form of CAN, FR frames or UDP data grams are converted to discoverable services at zones or can go directly to VC/HCP? In that scenario what about the control loop latency?
@@harikrishnaelaprolu2907 - The raw data can be converted to a service in the Zonal controller, or transported raw over Ethernet through the zone to other parts of the network. There are million ways to implement things. It is hard to give a concrete answer given the simplicity of the information on this RUclips chat.
Yes, we can say three ways of service processing 1. over edge, 2. over zone, 3. over central compute but not a million ways! Thanks