아이템/시스템: SbW(Steer by Wire), IDB, MGH 등 제품군 혹은 제품의 Variant를 뜻하는 의미로 생각됩니다.
컴포넌트: 아이템을 구성하는 하위 Sub 시스템(파워팩, 센서 등등)들을 컴포넌트로 부르거나, 
SW 관점에서는 하나의 Unit 과 같이 특정 기능을 수행하는 Function 단위로도 컴포넌트라는 단어로 불리는 것 같습니다.

Hacking into Toyota’s global supplier management network (eaton-works.com)

Key Points / Summary:

• I hacked Toyota’s Global Supplier Preparation Information Management System (“GSPIMS”), a web app used by Toyota employees and their suppliers to coordinate projects, parts, surveys, purchases, and other tasks related to the global Toyota supply chain.
• System Admin access achieved through accidentally introduced backdoor as part of a user impersonation/”Act As” feature.
• Any user could be logged in to just by knowing their email, completely bypassing the various corporate login flows.
• Read/write access to the global user directory containing 14k+ users was achieved.
• Data access achieved: 14k+ corporate user account details, confidential documents, projects, supplier rankings/comments, and more. Data access was global and not limited to North America.
• Issue was responsibly disclosed to Toyota in November 2022 and fixed in a timely manner.

Over the course of a slow week in late October 2022, I decided to explore the subdomains of various major companies to see if I could find any exploits worth reporting/writing about. I found several interesting Toyota websites. In 7 days, I reported 4 different security issues to Toyota, all of which were classified as “critical”. One of the reports had a remarkably severe impact and is one of the most severe vulnerabilities I have ever found (so far!)

I discovered what was essentially a backdoor login mechanism in the Toyota GSPIMS website/application that allowed me to log in as any corporate Toyota user or supplier just by knowing their email. I eventually uncovered a system administrator email and was able to log in to their account. Once that was done, I had full control over the entire global system. I used the word “staggering” to describe the amount of data I had access to in the Jacuzzi SmartTub hack, but that was relatively minor compared to this. I had full access to internal Toyota projects, documents, and user accounts, including user accounts of Toyota’s external partners/suppliers. External accounts include users from:

• Michelin
• Continental
• Stanley Black & Decker
• HARMAN
• Timken
• BOS
• Magna
• Many more (note the various email domains in the screenshots below)

GSPIMS stands for “Global Supplier Preparation Information Management System”. It is an Angular single-page-application. Based on a license key embedded in the app for AG Grid, it was created by SHI International Corp – USA on behalf of Toyota. At first, I didn’t know what GSPIMS was. Google showed a few job listings about it, but otherwise seemed obscure. I didn’t think it was that important at first, but I decided to put some time into it to see what might be hiding behind the login screen. It wasn’t until I bypassed the login screen that I saw the “Global Supplier Preparation Information Management System” label. Sounds important!

Bypassing the login

The login screen features corporate Toyota and Supplier login options:

There should be a “Are you a Hacker?” option.🙂

Both options supply the same list of login methods:

• TMNA = Toyota Motor North America
• TME = Toyota Motor Europe
• TMC = Toyota Motor Corporation (Japan)
• TDEM = Toyota Daihatsu Engineering & Manufacturing (Asia)
• Other Affiliates = Unknown, this button does not currently work

If you work for/with Toyota on any continent, it is likely you can log in to the system using one of these options. I do not work for Toyota, so I had to get past this login screen by patching the JavaScript code.

Developers control access to Angular routes/pages by implementing CanActivate and CanActivateChild. Basically, when a user attempts to navigate to a route/page, you would determine if they are allowed to view it, and then return true or false. By patching both to return true, you can usually fully unlock an Angular app:

The logout code also needed to be removed to prevent a redirect back to the login page:

With those patches applied, the app loads and can be browsed:

In the Jacuzzi SmartTub case, patching the JavaScript was all that was needed to achieve full access, since their API was improperly secured. In GSPIMS’ case, no data would load from the API. All the endpoints would return HTTP status 401 – Unauthorized responses due to the missing login cookie. This was the case for every page I browsed. Toyota/SHI had seemingly secured their API correctly, and at this point I was about to write this site off as “probably secure”. I don’t bother reporting single-page-application bypasses unless it also exposes a leaky/improperly secured API.

JWTs for everyone!

Before abandoning work on the GSPIMS app, I looked through its code to see if there might have been any API keys, secret API endpoints, or anything else that might be interesting. I came across this function in the user service. Can you spot what is interesting about it?

JWT stands for JSON Web Token. Think of it as a session token that represents your valid authenticated session on a website. You typically get a JWT after logging into a website using your email and password. You then provide the JWT to secured parts of a website or API to prove your identity and what you are allowed to access. More information

It is interesting because it appears to be generating a JWT based on a provided email. No password required. I decided to compose this HTTP request to see if that createJWT endpoint actually worked. Even if it worked, it wouldn’t be enough without a valid email, which could have been difficult to figure out, especially if the underlying userbase was small.

Corporate Toyota emails use a predictable format in North America: firstname.lastname@toyota.com. That made guessing a valid email easier, but I still had to find someone. I Googled for Toyota employees involved in the supply chain, hoping to find someone who may be registered in the GSPIMS system. I found a promising match and formulated their email address based on their name. Then I fired off the createJWT HTTP request, and it returned a valid JWT!

It seems like I had discovered a way to generate a valid JWT for any Toyota employee or supplier registered in GSPIMS, completely bypassing the various corporate login flows, which probably also enforce two-factor authentication options. The reason createJWT exists will be revealed later in this post.

Utilizing the JWT was easy. The GSPIMS API authenticates via cookie, so I just added it through Chrome’s dev tools:

Escalating to System Admin

The user I logged in had the role of “Mgmt – Purchasing” which probably means they are in charge of organizing purchases of things from suppliers through this system. I had access to some data at this point, but I felt there was more waiting to be unlocked. Looking at the HTTP requests and responses, there is a rolePrivileges node in the user/details API response that returns information about the currently logged in user:

I wanted to try and find a user with the System Admin role. I noticed another API endpoint named findByEmail that returned information about a user’s account by just providing a valid email. Conveniently, this also tells you who the user’s managers are:

Imagine having 3 different managers to report to!😱

Checking the managers of the managers, etc. made it easy to find accounts that had elevated access to the system. Eventually I found a North America Regional Admin. That gave me access to the User Administration section. I then poked around more and found users with even higher access, such as Supplier Admin, Global Admin, and finally, System Admin.

In the GSPIMS settings, the tabs that appear are dependent on your role. There’s Regional Settings for Regional Admins, Global Settings for Global Admins, and System Admin Settings for System Admins. System Admins can access all the tabs. I also noticed that System Admins had access to substantially more users in the User Administration section. Regional Admins are probably only able to manage users in their region, whereas System Admins could manage everyone. With a System Admin JWT, I basically had total, global control over the entire system.

A few screenshots of various sets of users. Take note of the user and page counts in the bottom right corner (there’s a lot – 14,063 users across 563 pages!) Click on any image to enlarge it in a new tab.

American users

Asian users

Japanese users

American System Admins

European users

More Japanese users

I could edit any of those users:

Or add a new user using the user import button above the columns. There is also an export users button you can use to download user information.

Exploring the impact

Having full access, I looked around the GSPIMS app to see what was available to me as a System Admin. I was very careful to not modify anything. Here’s the System Admin Settings if you are curious about what is there. Nothing too exciting – it just controls what roles can access certain features.

Now on to more interesting things. The Parts section has a list of parts associated with the various projects. You choose an affiliate at the top and then the project to see the list of parts. Here is the parts list for a project:

It’s worth noting the projects are in codenames/numbers. It didn’t say anything like “2024 Toyota Corolla”. With a lot more time I probably could have figured out the codenames, but that was outside the scope of this investigation. Speaking of projects, I had access to all the active, global, and inactive projects:

I could view the details of each project, including who is involved, the schedule and milestones, and some type of survey feature. Click on any image to enlarge it in a new tab.

Project Parts List

Add/Remove Users

Project Schedule

Surveys

System Management

Can’t forget about the documents! Classified documents are all the rage nowadays.

Reviewing the HTTP trace I captured, I noticed you can also see Toyota’s various comments about their suppliers. It’s probably also visible in the UI somewhere.

The HTTP trace was captured by just having Fiddler open while browsing the app. The API is very generous with the amount of data it returns, in particular with the users list. You could download a lot of user information by increasing the page size and flipping through the pages.

You could also see all the suppliers and how Toyota ranks them regarding risk, delivery, and prep. There are almost 3,000 of them:

Finally, I discovered what the createJWT API was actually used for. There is an “Act As” feature that let me log in as any of those 14k+ global users. I could easily log in as anyone and get an idea of what projects they are working on, their tasks, surveys, etc. Whoever made the Act As system apparently didn’t realize they added a backdoor to the entire system. The Act As feature is only visible to certain users, like the System Admin user I was logged in as.

That is one long drop-down list.

If a threat actor had discovered this issue, the consequences could have been severe. Here’s a few bad things they could have done. Please note that these are just ideas and none of these were carried out.

• Added their own user account with an elevated role, to retain access should the issue ever be discovered and fixed.
• Downloaded and leaked all the data.
• Delete everything or modify data in a way to be disruptive to global Toyota operations. Hopefully Toyota/SHI have working backups?
• Craft a highly targeted phishing campaign to attempt to capture real corporate login details, which could have exposed other Toyota systems to attacks. There’s 14k+ users available to attack. It’s one thing to have 14k+ corporate emails, but it’s another to have 14+ corporate emails and know exactly what they are working on/have worked on. If a supplier user has a habit of reusing passwords, it’s possible their own infrastructure could be attacked too.

Reporting to Toyota

The issue was reported to Toyota on November 3, 2022, and they responded later that same day confirming they received the report. On November 23, 2022 they confirmed the issue was remediated, although I noticed it was fixed before that when I randomly tested. I then informed them I would publish my writeup after the industry standard 90-day period has passed.

Toyota/SHI fixed the issue by making the createJWT and findByEmail endpoints return HTTP status 400 – Bad Request in all cases.

Out of all the security issues I have reported so far to various vendors, Toyota’s response was the fastest and most effective. I was very impressed with how quickly they responded and fixed the issue. Some companies can be slow to respond or fail to respond at all, so this experience was refreshing.

Thanks to this responsible disclosure, Toyota avoided what could have been a catastrophic leak of not only their own employees’ data, but the data of their partners/suppliers. Embarrassing internal comments and supplier rankings could have been published for the world to see. Toyota and their suppliers have been hit by cyberattacks before and it could have easily happened again.

Unfortunately, the reward for reporting this critical issue was $0. While it’s fun to find significant vulnerabilities like these, I will probably start shifting my efforts to companies offering monetary rewards help to sustain these often-lengthy investigations and writeups. PS: If you/your company’s security team are currently hiring, feel free to say hello🙂.

기술블로그 - INSIGHT - 페스카로(FESCARO) - 자동차 소프트웨어 전문기업(자동차 사이버보안, 제어기, V2X)

1. LIN 개요

1.1 LIN이란?

LIN(Local Interconnect Network)이란, 자동차 네트워크에서 컴포넌트들 사이의 통신을 위한 직렬 통신 시스템입니다. LIN은 CAN과 같이 다중화되고 있는 네트워크를 보완하기 위해 고안된 저가형 임베디드 네트워킹의 표준이며, 자동차 업계에서 가장 보편적으로 사용합니다. 대부분의 현대식 저가형 8비트 마이크로컨트롤러에 내장된 표준 시리얼 유니버셜 비동기 송/수신기(UART)를 사용하면 비교적 저렴하게 LIN통신을 구현할 수 있습니다. LIN은 보통 CAN의 고대역폭과 다기능이 필요하지 않은 액추에이터와 스마트 센서들 사이의 통신에 사용됩니다. 파워윈도우 기능, 좌식조절기 기능과 같이 그다지 높은 성능을 필요로하지 않는 기능들을 CAN으로 구현하기에는 많은 비용이 요구되므로, 이러한 기능들을 구현할 때에는 LIN을 사용합니다.

1.2 LIN 적용 대상 애플리케이션

이 외에도 LIN 통신은 주차할 때 갑자기 나타나는 장애물을 감지해 운전자에게 경고하는 전후방 주차보조시스템(PAS, Parking Assist System)과 주변 상황을 위에서 보듯 내려다봄으로써 주차할 때 옆 차와의 접촉 사고를 피하게 해주는 어라운드 뷰 모니터(AVM, Around View Monitor), 핸들 조작 없이 엑셀과 브레이크의 조작만으로 주차를 가능하게 하는 주차 조향 보조 시스템(SPAS, Smart Parking Assist System) 등과 같은 운전자 보조 시스템에 적용되고 있습니다.

1.3 LIN 특징1.3.1 단일 마스터-다중 슬레이브 구조

LIN 버스는 단일 마스터-다중 슬레이브 구조로 되어있어, CAN 프로토콜과는 달리 LIN 프로토콜은 버스 중재(메시지의 우선순위에 따라 어떤 메시지가 먼저 버스에 전송될지를 결정하는 것)를 하지 않습니다. LIN 프로토콜에서는 하나의 마스터 노드가 LIN 버스 내 모든 통신을 제어합니다. 이 마스터 노드로 인해 LIN 통신이 시작(메시지 전송 초기화)되며, 모든 슬레이브 노드는 마스터 노드의 허가를 받아야만 마스터 또는 버스 내에 있는 다른 슬레이브 노드들에게 응답을 할 수 있습니다.

1.3.2 멀티캐스트 수신

마스터 또는 슬레이브 태스크로부터 메시지 프레임이 전송될 때, 네트워크상에 연결된 모든 노드들은 메시지를 읽을 수 있습니다. 식별자 바이트에 따라, 수신 노드는 동작을 시작할 것인지 여부를 결정합니다.

1.3.3 클럭 동기화 방식

Synch Break에 이어 마스터 노드가 전송한 Synch Field를 이용하여 모든 슬레이브 노드들은 마스터 클럭에 동기를 맞춥니다.

1.3.4 가변 데이터 프레임

식별자 필드(그림 3 참조)의 두 비트(ID4, ID5)는 메시지 필드의 길이를 나타냅니다. 이 비트들을 이용하면 데이터의 길이를 조절 할 수 있습니다. 또한 송수신 데이터의 양이 제한되어 있을 때 데이터의 오버헤드를 줄여줍니다.

1.3.5 데이터 체크섬과 에러 검출

메시지 프레임에 포함된 데이터는 inverted modulo256-checksum으로, 식별자 바이트는 XOR 알고리즘으로 에러를 검출합니다.

1.3.6 네트워크 내 손상 노드 검출

마스터 태스크는 메시지 프레임의 전송을 제어하므로 모든 노드에게 정보를 요청하고, 각 노드들이 올바르게 동작하고 있는지 점검합니다.

2. LIN 버스 동작 원리

2.1 마스터 슬레이브 구조

LIN 버스는 마스터 슬레이브 구조로 되어있습니다. 이 구조에서는 하나의 마스터 노드가 네트워크 내 모든 통신을 제어합니다. LIN 버스는 데이터를 요청하거나 제어 명령을 전송하는 마스터 노드와 마스터 노드로부터의 데이터 요청에 상응하는 데이터를 수집하여 응답하거나 마스터 노드로부터 수신된 제어 명령에 상응하는 동작을 수행하는 슬레이브 노드들로 구성됩니다. 마스터 노드와 슬레이브 노드의 역할은 다음과 같습니다.

LIN 버스는 하나의 마스터 노드와 여러 개(최대 16개까지)의 슬레이브 노드들로 구성되어 있습니다. 또한 아래 그림과 같이 마스터 노드는 마스터 태스크와 슬레이브 태스크로 구성되어 있으며, 슬레이브 노드는 슬레이브 태스크만으로 구성되어 있습니다.

2.2 LIN 메시지 프레임

LIN 버스에서 전송의 기본 단위는 프레임이며, 이는 헤더(header)와 응답(response)으로 나뉘어집니다. 헤더는 항상 마스터 노드의 마스터 태스크가 전송하며, 3개의 필드(SYNC BREAK, SYNC, ID)로 구성됩니다. 응답은 슬레이브 태스크가 전송하며, 데이터 페이로드(DATA 1~n)와 체크섬(CHECKSUM)으로 구성됩니다.

2.2.1 LIN 메시지 헤더

1) 동기 브레이크 필드(SYNC BREAK Field)
메시지 프레임의 시작을 나타내는 필드입니다. 이 필드는 마스터 태스크가 전송(마스터 태스크만 전송 가능)하며, 슬레이브 태스크가 동기 필드를 준비할 수 있도록 합니다.

2) 동기 필드(SYNC Field)
슬레이브가 마스터 클럭과 동기를 맞추는데 필요한 신호가 포함된 필드입니다. 슬레이브들은 이 신호를 이용하여 현재의 bit time을 측정하고, 슬레이브 내부의 baud rate을 다시 계산하여 동기를 맞춥니다.

3) 식별자 필드(ID Field)
메시지의 내용(메시지의 주소)과 길이에 대한 정보를 나타내는 필드입니다. 식별자 필드는 메시지의 목적지를 가리키는 것이 아니라 메시지 프레임의 내용을 설명하여, 궁극적으로 LIN 네트워크에서 어떤 노드가 이 메시지에 어떻게 반응할지(수신, 응답 전송, 무시)를 결정하는 필드입니다.

헤더를 수신하면 모든 슬레이브 태스크는 메시지의 식별자(주소)를 확인하며 패리티를 검증하고, 수신할 것인지를 결정합니다. 만약 이 메시지에 대해 응답을 해야 한다면 슬레이브 태스크는 데이터 페이로드와 체크섬을 LIN 메시지 프레임의 응답부분에 채운 뒤 버스에 전송합니다.

2.2.2 LIN 메시지 응답

1) 데이터 필드(DATA Field)
데이터 필드는 8비트로 구성된 2~8개의 필드로 구성됩니다. 데이터 필드는 헤더의 식별자에 응답하는 슬레이브 태스크에 의해 쓰여집니다. 이 때, 버스 중재가 없기 때문에 단 하나의 슬레이브 태스크만 각 식별자에 대해 응답할 수 있으며, 다른 모든 슬레이브 태스크는 응답을 읽는 것이 제한됩니다.

2) 체크섬 필드(CHECKSUM Field)
모든 데이터 바이트(식별자를 포함하지 않은 데이터 프레임)의 modulo-256 합을 포함합니다. 이를 이용하여 메시지의 유효성을 판단합니다.

2.3 마스터 슬레이브 동작 과정 정리

LIN 네트워크는 마스터 슬레이브 구조로 동작하며, 마스터 노드의 마스터 태스크가 모든 LIN 네트워크 통신을 제어합니다. 마스터와 슬레이브의 동작을 도식으로 표현하면 다음과 같습니다.

3. LIN 버스의 두가지 상태

LIN 버스는 두가지 상태(Sleep 모드, Active)를 가집니다. 데이터가 버스에 있는 동안, 모든 노드는 Active 상태에 놓여집니다. 그러나 특정 시간(4초 이상)동안 버스가 유휴상태이면, 불필요한 전력을 낭비하지 않기 위해 마스터에 의해 LIN 버스는 저전력 동작 모드(Sleep 모드)로 전환됩니다. 또한 LIN 2.0부터 마스터가 첫 번째 바이트가 0이고, 식별자(ID)가 0x3C인 진단 프레임을 전송하면 모든 슬레이브들은 자동으로 Sleep 모드로 전환됩니다. 이러한 진단 프레임을 go-to-sleep-command라 부릅니다. 이후 다시 데이터가 감지되면(WAKEUP 프레임이 LIN 버스에 전송되면) 다시 정상모드(Active)로 복귀합니다.
WAKEUP 프레임은 Sleep 모드를 종료시키고 버스를 활성화시키기 위한 프레임입니다. WAKEUP은 버스가 sleep 모드이고, 노드 내부적으로 WAKEUP에 대한 요청이 있을 때 버스의 모든 노드(마스터, 슬레이브)에 의해 전송될 수 있습니다.

NeoIDM FOTA(Firmware over the air) ⑴ - 개요 : 네이버 블로그 (naver.com)

[그림 1] NeoIDM FOTA Work Flow

[그림 2] 버전 간 file system 비교

[그림 3] 버전 간 Flash Memory 비교

자료실 : MDS테크 (mdstech.co.kr)

[일반적인 FBL(Flash Bootloader) SW 구조]

 

C3-2.김휘강 (gagabox.com)

http://krnet.gagabox.com/board/data/dprogram/2355/C3-2_%B1%E8%C8%D6%B0%AD.pdf

현대 기아(HKMC) 용어 정의 : 네이버 블로그 (naver.com)

ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering

Introduction

Purpose of this document

This document addresses the cybersecurity perspective in engineering of electrical and electronic (E/E) systems within road vehicles. By ensuring appropriate consideration of cybersecurity, this document aims to enable the engineering of E/E systems to keep up with state-of-the-art technology and evolving attack methods.

This document provides vocabulary, objectives, requirements and guidelines related to cybersecurity engineering as a foundation for common understanding throughout the supply chain. This enables organizations to:

• — define cybersecurity policies and processes;
• — manage cybersecurity risk; and
• — foster a cybersecurity culture.

This document can be used to implement a cybersecurity management system including cybersecurity risk management.

Organization of this document

An overview of the document structure is given in Figure 1. The elements of Figure 1 do not prescribe an execution sequence of the individual topics.

Figure 1 — Overview of this document

Clause 4 (General considerations) is informational and includes the context and perspective of the approach to road vehicle cybersecurity engineering taken in this document.

Clause 5 (Organizational cybersecurity management) includes the cybersecurity management and specification of the organizational cybersecurity policies, rules and processes.

Clause 6 (Project dependent cybersecurity management) includes the cybersecurity management and cybersecurity activities at the project level.

Clause 7 (Distributed cybersecurity activities) includes requirements for assigning responsibilities for cybersecurity activities between customer and supplier.

Clause 8 (Continual cybersecurity activities) includes activities that provide information for ongoing risk assessments and defines vulnerability management of E/E systems until end of cybersecurity support.

Clause 9 (Concept) includes activities that determine cybersecurity risks, cybersecurity goals and cybersecurity requirements for an item.

Clause 10 (Product development) includes activities that define the cybersecurity specifications, and implement and verify cybersecurity requirements.

Clause 11 (Cybersecurity validation) includes the cybersecurity validation of an item at the vehicle level.

Clause 12 (Production) includes the cybersecurity-related aspects of manufacturing and assembly of an item or component.

Clause 13 (Operations and maintenance) includes activities related to cybersecurity incident response and updates to an item or component.

Clause 14 (End of cybersecurity support and decommissioning) includes cybersecurity considerations for end of support and decommissioning of an item or component.

Clause 15 (Threat analysis and risk assessment methods) includes modular methods for analysis and assessment to determine the extent of cybersecurity risk so that treatment can be pursued.

Clauses 5 through 15 have their own objectives, provisions (i.e. requirements, recommendations, permissions) and work products. Work products are the results of cybersecurity activities that fulfil one or more associated requirements.

“Prerequisites” are mandatory inputs consisting of work products from a previous phase. “Further supporting information” is information that can be considered, which can be made available by sources that are different from the persons responsible for the cybersecurity activities.

A summary of cybersecurity activities and work products can be found in Annex A.

Provisions and work products are assigned unique identifiers consisting of a two-letter abbreviation (“RQ” for a requirement, “RC” for a recommendation, “PM” for a permission and “WP” for a work product), followed by two numbers, separated by hyphens. The first number refers to the clause, and the second gives the order in the consecutive sequence of provisions or work products, respectively, of that clause. For example, [RQ-05-14] refers to the 14th provision in Clause 5, which is a requirement.

IoTSecurity101/README.md at master · V33RU/IoTSecurity101 · GitHub

https://jjeongil.tistory.com/177

SOME/IP 간략 소개

SOME/IP는 "Scalable service-Oriented MiddlewarE over IP"의 약자입니다. 이 미들웨어는 일반적인 자동차 사용 사례와 최소 유선 형식 수준의 AUTOSAR와 호환되도록 설계되었습니다.  http://some-ip.com/에서 공개적으로 액세스할 수 있는 사양이 제공됩니다. 이번 포스팅에서는 SOME/IP 사양의 기본 구조와 오픈 소스 구현 및 오픈 소스 구현에 대한 간략한 개요를 제공하고자 합니다.

먼저 SOME/IP 사양의 세 가지 주요 부분부터 살펴보겠습니다.

SOME/IP On-wire format

원칙적으로 SOME/IP 통신은 IP를 통해 devices 또는 subscribers 간에 전송되는 메시지로 구성됩니다. 다음 그림을 참고하세요.

두 장치(A 및 B)가 표시되어 있습니다. Device A는 B에 SOME/IP 메시지를 보내고 하나의 메시지를 반환합니다. 기본 전송 프로토콜은 TCP 또는 UDP를 활용합니다. 메시지 자체에는 큰 차이가 없습니다. 이제 Device B에서 이 메시지에 의해 Device  A에서 호출되는 기능을 제공하는 서비스를 실행하고 있다고 가정하고, 그 답으로 메시지를 보냅니다.

SOME/IP 메시지에는 header와 payload의 두 부분이 있습니다. 그림에서 헤더는 주로 식별자입니다:

정상적인 기능 호출과 클라이언트가 가입한 이벤트에 대한 알림 메시지에 "Requests" 및 "RESPONSE"가 있음을 알 수 있습니다. 오류는 정상적인 응답 또는 알림으로 보고되지만 적절한 반환 코드가 있습니다.

payload에는 직렬화된 데이터가 포함되어 있습니다. 위 그림은 전송된 데이터 구조가 기본 데이터 유형만 있는 중첩 구조라는 단순한 경우의 직렬화를 보여주고 있습니다. 이 경우, 구조 요소는 그냥 평평하게 됩니다. 즉, 단순히 적재물에 하나씩 기록된다는 뜻입니다.

SOME/IP Protocol

이 섹션에서는 주로 두 가지 사항이 중요합니다.

위에서 언급한 바와 같이 기본 전송 프로토콜은 UDP 또는 TCP일 수 있습니다. UDP의 경우 SOME/IP message가 분할되지 않습니다. message가 둘 이상 UDP 패킷에 있을 수 있지만 UDP 패키지는 최대 1400바이트일 수 없습니다. 큰 message는 TCP를 통해 전송되어야 합니다. 이 경우 TCP의 robustness가 사용됩니다. TCP 스트림에서 동기화 오류가 발생하면 SOME/IP 규격에서 다음 message의 시작을 다시 찾기 위해 magic cookies를 호출할 수 있습니다.

service interfaces를 인스턴스화해야 하며 동일한 인터페이스의 인스턴스가 여러 개 있을 수 있으므로 정의된 인스턴스(인스턴스 ID)에 대한 추가 식별자가 있어야 합니다. 그러나 인스턴스 ID는 SOME/IP 메시지 header의 일부가 아닙니다. 인스턴스는 전송 프로토콜의 포트 번호를 통해 식별됩니다. 즉, 동일한 인터페이스에서 여러 인스턴스가 동일한 포트에서 제공될 수 없습니다.

이제 기본 SOME/IP 통신 패턴을 보여 주는 다음 그림을 보십시오.

Remote Procedure Calls에 대한 표준 REQUEST/RESPONSE 메커니즘 외에도 이벤트에 대한 PUBLISH/SUBSCRIBE 패턴도 있습니다. SOME/IP 프로토콜의 이벤트는 항상 이벤트 그룹에 그룹화되므로 이벤트 자체는 가입할 수 없고 이벤트 그룹에만 가입할 수 있습니다. SOME/IP 사양도 "필드"를 알고 있습니다. 이 경우 Setter/Getter 방법이 REQUEST/RESPONSE 패턴을 따르고 있으며 변경사항의 알림 message는 이벤트입니다. Subscription 자체는 SOME/IP Service Discovery을 통해 수행됩니다.

SOME/IP Service discovery

SOME/IP 서비스 검색은 서비스 인스턴스를 찾고 서비스 인스턴스가 실행 중인지 탐지하고 publish/subscribe 처리를 구현하는 데 사용됩니다. 이것은 소위 말하는 offer messages를 통해 수행됩니다. 즉, 각 device는 이 device에서 제공하는 모든 서비스를 포함하는 메시지를 broadcast(멀티캐스트)합니다. SOME/IP SD messages는 UDP를 통해 전송됩니다. 클라이언트 애플리케이션에 서비스가 필요하지만 현재 제공되지 않는 경우 "find messages"도 보낼 수 있습니다. 다른 SOME/IP SD messages는 이벤트 그룹을 Publish/Subscribe하는 데 사용할 수 있습니다.

다음 그림은 SOME/IP SD messaged의 일반적인 구조를 보여줍니다.

vsomeip 간단 개요

도입 사례를 구현하기 전에 vsomeip이라고 하는 SOME/IP의 GENIVI 구현의 기본 구조에 대해 간단히 살펴보겠습니다.

그림과 같이 vsomeip은 기기 간 SOME/IP communication (외부 통신)뿐만 아니라 내부 프로세스 간 communication 도 포함합니다. 두 Device는 사용된 전송 프로토콜(TCP 또는 UDP)과 해당 매개 변수를 포트 번호 또는 기타 매개 변수로 결정하는 통신 endpoints 을 통해 통신합니다. 이러한 모든 매개 변수는 vsomeip 구성 파일에 설정할 수 있는 구성 매개 변수입니다(json 파일, vsomeip 사용자 설명서 참조). 내부 communication은 로컬 endpoint를 통해 이루어지며, 이 엔드포인트는 Boost.Asio Library를 사용하여 Unix 도메인 소켓에 의해 구현됩니다. 이 내부 통신은 D-Bus 데몬과 같은 중앙 구성 요소를 통해 라우팅되지 않으므로 매우 빠릅니다.

중앙 vsomeip 라우팅 관리자는 외부 디바이스로 전송해야 하는 경우에만 messages를 수신하고 외부에서 들어오는 messages를 배포합니다. Device 당 라우팅 관리자는 하나만 있으며, 아무것도 구성되지 않은 경우 실행 중인 vsomeip 애플리케이션도 라우팅 관리자를 시작합니다.

vsomeip은 데이터 구조의 직렬화를 구현하지 않습니다. 이는 CommonAPI의 SOME/IP Binding에서 다루고 있습니다. vsomeip은 SOME/IP Protocol과 Service Discovery을 포함합니다.

이는 SOME/IP 및 vsomeip에 대한 짧은 소개였습니다  그러나 처음 접하시는 분들에게는 충분할 것입니다. 더 자세한 것은 나중에 예제를 통해 설명하도록 하겠습니다.