https://tb.kibo.or.kr/ktms/board/download.do?rbsIdx=441&idx=403&fidx=1&usg=AOvVaw055O89vj3goNb6vkVO-DZL 

TELECHIPS社 TCC8925 안드로이드용 : 네이버 블로그 (naver.com)

TCC 8925

ASIL(Automotive Safety Integrity Level) ISO 26262 자동차 안전 무결성 등급 (tistory.com)

정의

ASIL은 자동차 안전 무결성 수준을 나타냅니다. 도로 차량의 기능 안전을 위해 ISO 26262 표준에 정의된 위험 분류 시스템입니다.

이 표준은 기능 안전을 "전기 또는 전자 시스템의 오작동 동작으로 인한 위험으로 인한 불합리한 위험이 없음"으로 정의합니다. ASIL은 자동차 부품이 ISO 26262를 준수하기 위해 위험 가능성과 허용 가능성을 기반으로 하는 안전 요구 사항을 설정 합니다.

ISO 26262-A, B, C 및 D에 의해 식별된 4 개의 ASIL이 있습니다. ASIL A는 가장 낮은 등급을 나타내고 ASIL D는 가장 높은 수준의 자동차 위험을 나타냅니다.

에어백, 잠금 방지 브레이크 및 파워 스티어링과 같은 시스템은 고장과 관련된 위험이 가장 높기 때문에 안전 보증에 적용되는 가장 엄격한 ASIL-D 등급이 필요합니다. 안전 스펙트럼의 다른 쪽 끝에서 후방 조명과 같은 구성 요소는 ASIL-A 등급만 필요합니다. 헤드 라이트와 브레이크 라이트는 일반적으로 ASIL-B이고 크루즈 컨트롤은 일반적으로 ASIL-C입니다.

ASIL은 어떻게 작동합니까?

ASIL은 위험 분석 및 위험 평가를 수행하여 설정됩니다. 차량의 각 전자 부품에 대해 엔지니어는 세 가지 특정 변수를 측정합니다.

• 심각도 (운전자와 승객의 부상 유형)
• 노출 (차량이 위험에 노출되는 빈도)
• 조종성 (운전자가 부상을 방지하기 위해 할 수 있는 정도)

이러한 각 변수는 하위 클래스로 분류됩니다. 심각도에는 "부상 없음"(S0)에서 "생명을 위협하는 / 치명적 부상"(S3)까지 네 가지 등급이 있습니다. 노출에는 "매우 가능성이 낮음"(E0)에서 "매우 가능성이 높음"(E4)까지 다섯 가지 등급이 있습니다. 제어 가능성에는 "일반적으로 제어 가능"(C0)에서 "제어 불가능"(C3)까지 네 가지 등급이 있습니다.

모든 변수와 하위 분류를 분석하고 결합하여 필요한 ASIL을 결정합니다. 예를 들어, 가장 높은 위험 (S3 + E4 + C3)의 조합은 ASIL D 분류가 됩니다. 

ASIL의 과제는 무엇입니까?

ASIL을 결정하려면 많은 변수가 필요하며 엔지니어가 가정을 해야 합니다. 예를 들어 구성 요소가 가상적으로 "제어할 수 없음"(C3)이고 오작동할 경우 "생명을 위협 / 치명적 부상"(S3)을 유발할 가능성이 있는 경우에도 간단히 ASIL A (낮은 위험)로 분류될 수 있습니다. 위험 노출 가능성 (E1)이 낮습니다.

ASIL은 어떻게 진화하고 있습니까?

ASILS 결정과 관련된 추측을 고려할 때,  SAE (Society of Automotive Engineers)  는 2015 년에 J2980, "ISO 26262 ASIL 위험 분류에 대한 고려 사항"초안을 작성했습니다. 이러한 지침은 주어진 위험에 대한 노출, 심각도 및 제어 가능성을 평가하기 위한 보다 명확한 지침을 제공합니다. J2980은 계속 진화하고 있으며 SAE는 2018 년에 개정판을 발표했습니다.

자율 주행 자동차의 진화와 함께 ISO 26262는 현재 인간 운전자와 관련된 "제어 가능성"의 정의를 다시 검토해야 합니다. 표준에 따르면, 인간 운전자가 없다는 것은 제어 가능성이 항상 "제어 불가능"의 극단인 C3임을 의미합니다. 심각도 (부상) 및 노출 (확률)의 다른 변수도 재검토가 필요합니다.

ASIL의 이점은 무엇입니까?

ISO 26262는 "위험 방지"에 관한 모든 목표 기반 표준입니다. 어려움에도 불구하고 ASIL 분류는 "위험을 방지"하고 길고 종종 분리된 공급망에서 수많은 자동차 부품에 대해 가능한 최고의 안전 등급을 달성하는 데 도움이됩니다.

주요 이점은 다음과 같습니다.

• 위험을 허용 가능한 수준으로 완화하기 위한 안전 요구 사항 설정
• 안전 요구 사항 관리 및 추적
• 최종 제품에서 표준화된 안전 절차를 따랐는지 확인 

Synopsys는 ASIL 요구 사항을 충족하는 데 어떻게 도움이됩니까?

안전 패키지가 포함 된 Synopsys DesignWare IP 포트폴리오는 ASIL B 및 D 지원, ISO 26262 인증을 받았으며 안전이 중요한 애플리케이션에서 사용하도록 설계되었습니다. ASIL 인증 IP는 또한 ADAS (Advanced Driver Assistance System) 와 같은 애플리케이션을 위한 SoC 개발을 가속화 합니다.

당사의 안전 패키지는 고장 모드 효과 및 진단 분석 (FMEDA) 보고서, 안전 매뉴얼 및 인증 보고서로 구성되어 안전 평가를 가속화하고 목표 ASIL에 도달하는 데 도움을 줍니다. 또한 DesignWare IP를 사용하면 공급망 위험을 줄이고 SoC 수준의 기능 안전을 달성하는 전체 프로세스 (요구 사양에서 설계, 구현, 통합, 검증, 검증 및 구성까지)를 가속화 할 수 있습니다. 

VN5620 / VN5430 | Vector

VN5620/VN5430 – 차량용 Ethernet 및 CAN/CAN FD를 위한 고성능 네트워크 인터페이스

 

(주)임베디드시스템코리아 쇼핑몰에 오신 것을 환영합니다! (eskorea-shop.kr)

 

(주)임베디드시스템코리아 쇼핑몰에 오신 것을 환영합니다!

Q A

www.eskorea-shop.kr

 

 

WP29 checklist_1.pdf (autocrypt.co.kr)

출처 : UN 유럽 경제위원회 정보부 면책 조항 :이 문서는 정보 제공만을 목적으로 합니다. 특정 문제 또는 사실적 상황에 대한 법적 의견 또는 법적 조언에 의존하거나 해석해서는 안됩니다. WP.29 의 궁금한 사항은 AUTOCRYPT 팀에 직접 문의 부탁드립니다. UNECE WP.29 체크리스트 2020 년 6 월 UN 은 자동차 사이버 보안에 관한 두 가지 새로운 규정을 공식적으로 채택했습니다. 이에 따라 자동차 산업에 종사하는 경우 조직에서 수행해야 하는 몇 가지 작업 (OEM, Tier-1 공급 업체, 소프트웨어 제공 업체 등)이 있습니다. CYBER SECURITY MANAGEMENT SYSTEMS (CSMS).. 일반 산업 / 부문 차량 설계에서 사이버 보안 위험 식별 및 관리 테스트를 포함한 위험관리 확인 위험평가가 최신 상태로 유지되고 있는지 확인 사이버 공격 모니터링 및 대응 사이버 보안 성공된 사례 분석 지원 새로운 위협 및 취약성 평가 제조업체 부문 CSMS 차량적용가능 확인 위험평가 분석 및 주요사항 식별 위험을 줄이기 위한 완화 조치 식별 완화 조치가 의도대로 작동하는지 식별 사이버공격에 대한 예방조치 확인 차량 유형별 활동 모니터링 모니터링 활동 보고서 승인기관 전송 SOFTWARE UPDATE MANAGEMENT SYSTEMS (SUMS).. 일반 산업 / 부문 차량유형에 대한 하드웨어 및 소프트웨어 버전 기록 형식승인과 관련된 소프트웨어 식별 소프트웨어 구성요소 확인 소프트웨어 업데이트 및 상호 종속성 확인 차량 표적 식별 및 소프트웨어 업데이트 호환성 확인 소프트웨어 업데이트가 매개변수에 영향을 미치는지 확인 소프트웨어 업데이트가 안전에 영향을 미치는지 확인 차량 소유자에게 소프트웨어 업데이트 알림 제조업체 부문 SUMS 차량적용가능 확인 소프트웨어 매커니즘 보호 및 무결성 보장 소프트웨어 식별번호 보호 차량에서 소프트웨어 식별번호 가능여부 확인 출처 : UN 유럽 경제위원회 정보부 면책 조항 :이 문서는 정보 제공만을 목적으로 합니다. 특정 문제 또는 사실적 상황에 대한 법적 의견 또는 법적 조언에 의존하거나 해석해서는 안됩니다. WP.29 의 궁금한 사항은 AUTOCRYPT 팀에 직접 문의 부탁드립니다. OVER-THE-AIR (OTA) SOFTWARE UPDATES.. 업데이트 실패 시 복원기능 전원이 충분한 경우만 업데이트 실행 안전한 실행 보장 사용자에게 업데이트 완료됨을 확인 필요 차량이 업데이트 실행이 가능한지 확인 필요 정비가 필요할 경우 사용자에게 알림 필요

아이템/시스템: 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에 대한 요청이 있을 때 버스의 모든 노드(마스터, 슬레이브)에 의해 전송될 수 있습니다.