Runnable và Sự kiện (Event) trong AUTOSAR

0
Runnable Và Sự Kiện (event) Trong Autosar
Runnable Và Sự Kiện (event) Trong Autosar

Trong tiêu chuẩn AUTOSAR, Runnable và Event đóng vai trò then chốt. Hai yếu tố này là trung tâm trong thiết kế và triển khai hệ thống dựa trên AUTOSAR, và việc hiểu rõ chúng là điều cần thiết để nắm bắt được toàn bộ hệ sinh thái phức tạp của AUTOSAR.
Trang này sẽ cung cấp cái nhìn tổng quan về các khái niệm cơ bản của Runnable và Event trong AUTOSAR, cũng như cách chúng tương tác với nhau.

Runnable trong AUTOSAR

Runnable là đơn vị thực thi nhỏ nhất trong một thành phần phần mềm (Software Component, SWC). Runnable là viết tắt của “Runnable Entity” và đại diện cho một phần mã thực sự được thực thi. Nói đơn giản, Runnable là một hàm hoặc một khối lệnh có thể được thực thi độc lập trong một SWC cụ thể.
Runnable được kích hoạt bởi một sự kiện cụ thể hoặc được thực thi theo chu kỳ thời gian nhất định.

• Tính độc lập: Runnable có thể được thực thi độc lập và mỗi Runnable có vai trò và trách nhiệm rõ ràng.
• Thực thi dựa trên sự kiện: Runnable được bắt đầu thực thi bởi một sự kiện hoặc điều kiện cụ thể.
• Tính tái sử dụng: Runnable thực hiện một chức năng cụ thể có thể được tái sử dụng trong các Component khác.

Runnable có thể đảm nhiệm nhiều vai trò khác nhau tùy thuộc vào trường hợp sử dụng thực tế. Ví dụ, một Runnable có thể kiểm tra nhiệt độ động cơ, trong khi một Runnable khác có thể giám sát trạng thái của hệ thống phanh.

Runnable Và Sự Kiện (event) Trong Autosar
Runnable Và Sự Kiện (event) Trong Autosar

Cấu trúc và Nguyên lý Hoạt động của Runnable

Runnable được gọi bởi Run-Time Environment (RTE) khi một sự kiện cụ thể xảy ra hoặc khi đến thời điểm đã định. Sau đó, Runnable sẽ thực thi theo logic đã được định nghĩa và, nếu cần, có thể gọi các chức năng từ các thành phần phần mềm khác hoặc Basic Software (BSW).

• Cổng nhập/xuất (Input/Output Ports): Runnable sử dụng các cổng này để nhận dữ liệu đầu vào và xuất kết quả.
• Điều kiện thực thi: Xác định sự kiện hoặc điều kiện nào sẽ kích hoạt Runnable.
• Logic: Khối mã thực tế mà Runnable sẽ thực hiện.

Cấu Trúc Và Nguyên Lý Hoạt động Của Runnable
Cấu Trúc Và Nguyên Lý Hoạt động Của Runnable

Sự kiện (Event) trong AUTOSAR

Runnable là đơn vị thực thi nhỏ nhất trong một thành phần phần mềm và được kích hoạt bởi một sự kiện (Event) hoặc được thực thi theo chu kỳ thời gian nhất định. Nói một cách đơn giản, Event là tín hiệu hoặc trình kích hoạt thông báo rằng Runnable cần được thực thi khi một điều kiện cụ thể được đáp ứng.

• Cơ chế kích hoạt: Event đóng vai trò kích hoạt việc thực thi của một Runnable cụ thể.
• Nguồn đa dạng: Event có thể đến từ nhiều nguồn khác nhau như đầu vào của người dùng, dữ liệu từ cảm biến, bộ đếm thời gian, hoặc thông điệp mạng.
• Đồng bộ và Bất đồng bộ: Event có thể kích hoạt Runnable một cách đồng bộ hoặc bất đồng bộ.

Event có thể được sử dụng trong nhiều tình huống khác nhau. Ví dụ, khi tốc độ xe vượt quá một ngưỡng nhất định, một Event có thể được thiết lập để kích hoạt Runnable “Cảnh báo quá tốc độ”. Hoặc, khi động cơ quá nóng, một Event có thể kích hoạt Runnable “Dừng khẩn cấp”.

Runnable Là đơn Vị Thực Thi Nhỏ Nhất
Runnable Là đơn Vị Thực Thi Nhỏ Nhất

Phân loại và Nguyên lý Hoạt động của Sự kiện (Event)

Event và Runnable có mối quan hệ chặt chẽ. Khi một Event xảy ra, Runnable liên quan sẽ được thực thi. Quá trình này được quản lý bởi Run-Time Environment (RTE), nơi quyết định thứ tự và mức độ ưu tiên của việc thực thi Runnable.

• Sự kiện thời gian (Timing Event): Kích hoạt Runnable sau một khoảng thời gian hoặc độ trễ nhất định. Ví dụ: Thực thi một Runnable sau mỗi 10 ms để kiểm tra nhiệt độ động cơ.
• Sự kiện dữ liệu (Data Event): Kích hoạt Runnable khi có sự thay đổi dữ liệu cụ thể, chẳng hạn như thay đổi giá trị cảm biến. Ví dụ: Khi giá trị của cảm biến nhiệt độ thay đổi, Runnable giám sát nhiệt độ động cơ sẽ được kích hoạt.
• Sự kiện hoạt động (Operation Event): Kích hoạt Runnable dựa trên hoạt động của Runnable hoặc Component khác. Ví dụ: Khi một Runnable khác hoàn thành việc kiểm tra hệ thống phanh, Runnable giám sát an toàn sẽ được kích hoạt.

Nhờ sự phân loại này, hệ thống AUTOSAR có thể linh hoạt và đáp ứng nhanh chóng với các tình huống khác nhau trong quá trình hoạt động, đảm bảo hiệu suất và an toàn cho xe.

Phân Loại Và Nguyên Lý Hoạt động Của Sự Kiện (event)
Phân Loại Và Nguyên Lý Hoạt động Của Sự Kiện (event)

Cổng (Port) & Giao diện (Interface) trong AUTOSAR

0
Port Và Interface Trong Autosar
Port Và Interface Trong Autosar

AUTOSAR cung cấp một kiến trúc tiêu chuẩn hóa cho phép các thành phần phần mềm trong ô tô giao tiếp và hoạt động hiệu quả. Trong kiến trúc này, Port và Interface đóng vai trò trung tâm trong việc truyền dữ liệu và cung cấp dịch vụ giữa các thành phần. Do đó, hiểu rõ hai yếu tố này là điều cần thiết để xây dựng và vận hành hệ thống AUTOSAR đúng cách.
Trang này sẽ giới thiệu khái quát về các khái niệm cơ bản trong kiến trúc AUTOSAR, sau đó giải thích các loại Port và Interface, cách chúng hoạt động, và cách chúng tương tác với nhau.

Port và Interface trong AUTOSAR

Trong AUTOSAR, nhiều thành phần phần mềm giao tiếp và hoạt động cùng nhau. Việc truyền thông này chủ yếu được thực hiện thông qua Port và Interface.
• Cổng (Ports): Là điểm kết nối cho phép thành phần phần mềm giao tiếp với bên ngoài.
• Giao diện (Interfaces): Định nghĩa quy chuẩn hoặc giao thức được sử dụng để thực sự gửi và nhận dữ liệu qua Port. Hai loại phổ biến là giao diện Gửi-Nhận (Sender-Receiver Interface) và giao diện Khách hàng-Máy chủ (Client-Server Interface).

Port Và Interface Trong Autosar
Port Và Interface Trong Autosar

Giao diện trong AUTOSAR – Interface

AUTOSAR cung cấp nhiều loại giao diện khác nhau để sử dụng tùy theo mục đích và đặc tính của truyền thông. Sender-Receiver tập trung vào việc truyền dữ liệu đơn giản và thường sử dụng giao tiếp bất đồng bộ. Ngược lại, Client-Server tập trung vào việc cung cấp dịch vụ phức tạp và có thể hỗ trợ giao tiếp đồng bộ.

1. Giao diện Gửi-Nhận (Sender-Receiver Interface)

• Sender đóng vai trò gửi dữ liệu, trong khi Receiver đóng vai trò nhận dữ liệu.
• Chủ yếu hỗ trợ giao tiếp bất đồng bộ, phù hợp với việc trao đổi dữ liệu đơn giản. Thông thường, một Sender Port có thể kết nối với một hoặc nhiều Receiver Port.
• Khi Sender gửi dữ liệu, dữ liệu này sẽ được truyền ngay lập tức đến Receiver đã kết nối.
• Thường sử dụng hàng đợi thông điệp hoặc bộ đệm và không có quá trình yêu cầu-phản hồi riêng biệt.

Giao Diện Gửi-nhận (sender-receiver Interface)
Giao Diện Gửi-nhận (sender-receiver Interface)

2. Giao diện Khách -Máy chủ (Client-Server Interface)

• Client gửi yêu cầu dịch vụ, trong khi Server thực hiện dịch vụ được yêu cầu và trả lại kết quả. Giao diện này chủ yếu hỗ trợ giao tiếp đồng bộ, phù hợp với các tác vụ hoặc yêu cầu dịch vụ phức tạp.
• Client yêu cầu một tác vụ hoặc dịch vụ cụ thể từ Server.
• Server thực hiện tác vụ đó và sau đó trả lại kết quả cho Client. Quá trình này bao gồm một cơ chế yêu cầu-đáp ứng.
Port trong AUTOSAR
Port đóng vai trò trung tâm trong truyền thông giữa các thành phần phần mềm trong AUTOSAR, là điểm kết nối để gửi và nhận dữ liệu hoặc dịch vụ thông qua một Interface cụ thể.
• P-Port (Provided Port): Là Port dùng để xuất dịch vụ hoặc dữ liệu mà thành phần cung cấp ra bên ngoài.
• R-Port (Required Port): Là Port dùng để nhận dịch vụ hoặc dữ liệu mà thành phần cần từ bên ngoài.

Giao Diện Khách -máy Chủ (client-server Interface)
Giao Diện Khách -máy Chủ (client-server Interface)

Các thành phần phần mềm trong AUTOSAR – Software Component

0
Các Thành Phần Phần Mềm Trong Autosar - Software Component
Các Thành Phần Phần Mềm Trong Autosar - Software Component

AUTOSAR cung cấp một kiến trúc hệ thống ô tô được mô-đun hóa và tiêu chuẩn hóa, cho phép phần mềm của nhiều nhà cung cấp tương thích với nhau. Đặc biệt, các thành phần phần mềm (Software Components) trong AUTOSAR là đơn vị cơ bản để cấu thành hệ thống phức tạp, giúp phát triển và bảo trì hiệu quả cũng như tái sử dụng cao.
Trang này sẽ giới thiệu về các khái niệm cơ bản của AUTOSAR và cấu trúc của các thành phần phần mềm.

Các thành phần phần mềm trong AUTOSAR

Các thành phần phần mềm (SWC, Software Components) có thể được coi như “mảnh ghép” của phần mềm, chịu trách nhiệm cho các chức năng hoặc logic độc lập. Những thành phần này mang lại lợi ích về tái sử dụng, bảo trì, và mở rộng, giúp xây dựng và quản lý các hệ thống phần mềm phức tạp một cách dễ dàng hơn.
Trong AUTOSAR, các thành phần phần mềm đóng một vai trò đặc biệt quan trọng. Chúng hiện thực hóa các chức năng khác nhau của ô tô, như hệ thống phanh, hệ thống định vị, quản lý động cơ, v.v., dưới dạng mô-đun hóa. Kỹ sư ô tô có thể kết hợp các thành phần này để xây dựng phần mềm phù hợp với từng mẫu xe hoặc hệ thống cụ thể một cách hiệu quả.

Các Thành Phần Phần Mềm Trong Autosar - Software Component
Các Thành Phần Phần Mềm Trong Autosar – Software Component

Các thành phần của SWC

AUTOSAR Software Component (SWC) chủ yếu được cấu thành từ các thành phần như “Runnable Entity”, “Port”, và “Interface”.

• Runnable Entity: Đây là các khối chức năng có thể thực thi, thực hiện một tác vụ cụ thể.
• Port: Giao diện để truyền dữ liệu và yêu cầu dịch vụ giữa các thành phần.
• Interface: Định nghĩa loại dữ liệu và phương thức mà Port có thể sử dụng.

Bằng cách xác định cách các thành phần này kết nối và hoạt động cùng nhau, mỗi SWC có thể thực hiện một chức năng độc lập. Các thành phần được tạo ra theo cách này có thể tái sử dụng trong nhiều hệ thống phần mềm ô tô khác nhau, giúp tiết kiệm đáng kể thời gian và chi phí phát triển.
Khái niệm về Software Component này góp phần lớn vào mục tiêu tiêu chuẩn hóa và mô-đun hóa của kiến trúc AUTOSAR, cung cấp nền tảng để quản lý và phát triển các hệ thống ô tô phức tạp một cách hiệu quả hơn.

Runnable Entity, Port, Interface
Khái niệm về Software Component

Runnable Entity, Port, Interface

Runnable Entity

Runnable Entity là các khối mã thực thi thực sự trong AUTOSAR Software Component. Đây là những đoạn mã có thể chạy, thực hiện các chức năng hoặc logic cụ thể. Runnable Entity được thực thi dựa trên một sự kiện hoặc điều kiện cụ thể, và kết quả thường được truyền đến các thành phần khác thông qua Port.

Port

Port là điểm kết nối để trao đổi dữ liệu hoặc dịch vụ giữa các thành phần. Có hai loại Port là “Provider Port” và “Requirer Port”.
• P Port (Provider Port): Cung cấp dịch vụ hoặc dữ liệu từ thành phần này cho bên ngoài.
• R Port (Requirer Port): Nhận dịch vụ hoặc dữ liệu cần thiết từ các thành phần bên ngoài.

Interface

Interface định nghĩa loại dữ liệu và phương thức mà Port có thể sử dụng. Đây là một dạng “hợp đồng” giúp xác định rõ ràng sự tương tác giữa các thành phần.

Runnable Entity, Port, Interface
Runnable Entity, Port, Interface

Hiểu về Kiến trúc E-GAS 3 Cấp độ theo ISO 26262

Hiểu Về Kiến Trúc E-gas 3 Cấp độ Theo Iso 26262
Hiểu Về Kiến Trúc E-gas 3 Cấp độ Theo Iso 26262

Trung tâm của ngành công nghiệp ô tô là kiến trúc phần mềm phức tạp và an toàn chức năng. Trong bối cảnh này, kiến trúc E-GAS đóng một vai trò đặc biệt quan trọng. Tuy nhiên, đối với những người mới tiếp xúc, kiến trúc E-GAS có thể khá phức tạp và khó hiểu.
Trang này sẽ giải thích chi tiết về các khái niệm cơ bản và các yếu tố cụ thể của kiến trúc E-GAS.

Kiến trúc E-GAS

Kiến trúc E-GAS xuất hiện vào những năm 1990 và ban đầu được sử dụng như một tiêu chuẩn để đảm bảo an toàn chức năng cho động cơ xăng. Vào thời điểm đó, do chưa có các tiêu chuẩn như ISO 26262, E-GAS đóng vai trò quan trọng trong việc đảm bảo tính an toàn của hệ thống quản lý động cơ ô tô.
Với sự ra đời của tiêu chuẩn ISO 26262, tầm quan trọng của an toàn chức năng trong phần mềm ô tô đã được nhấn mạnh hơn nữa. E-GAS đã được liên kết với ISO 26262 để đảm bảo an toàn chức năng một cách có hệ thống hơn. ISO 26262 giới thiệu khái niệm ASIL (Automotive Safety Integrity Level) – Mức độ Toàn vẹn An toàn Ô tô, và kiến trúc E-GAS cũng cung cấp nhiều cấp độ giám sát dựa trên ASIL.

Các thành phần của E-GAS 3 Cấp độ

Kiến trúc E-GAS bao gồm nhiều cấp độ giám sát nhằm đảm bảo an toàn chức năng của phần mềm ô tô. Mỗi cấp độ có các chức năng và mục tiêu độc lập, đảm bảo an toàn theo tiêu chuẩn ASIL của ISO 26262.

Cấp độ 1: Chức năng Điều khiển Dự định và QM

Cấp độ 1 đảm nhận các chức năng điều khiển chính của ô tô và thường có mức độ toàn vẹn QM (Quality Management). Ví dụ, logic điều khiển cơ bản như kiểm soát động cơ và hệ thống phanh nằm trong cấp độ này.

Cấp độ 2: Giám sát Chức năng và ASIL

Cấp độ 2 đóng vai trò giám sát để đảm bảo các chức năng của cấp độ 1 hoạt động chính xác. Ở cấp độ này, tiêu chuẩn ASIL được áp dụng để đảm bảo mức độ an toàn cao hơn. Cấp độ 2 sử dụng các lõi hoặc thuật toán khác nhau để phát hiện lỗi ở cấp độ 1 và chuyển hệ thống sang trạng thái an toàn khi cần thiết.

Cấp độ 3: Giám sát Bộ điều khiển và ASIL

Cấp độ 3 liên tục giám sát trạng thái của MCU hoặc các bộ điều khiển khác để duy trì sự ổn định của toàn hệ thống. ASIL cũng được áp dụng ở cấp độ này và thường được chia thành hai phần:
• Giám sát bên trong MCU chính
• Giám sát các MCU, ASIC, hoặc SBC (như PMIC) khác
Ở cấp độ này, các yếu tố như BIST (Built-In Self-Test), ECC (Error-Correcting Code), đơn vị giám sát xung nhịp, và bộ điều khiển quản lý năng lượng hoạt động cùng nhau để tăng cường tính an toàn của hệ thống.

Hiểu Về Kiến Trúc E-gas 3 Cấp độ Theo Iso 26262
Hiểu Về Kiến Trúc E-gas 3 Cấp độ Theo Iso 26262

Ưu điểm của Kiến trúc E-GAS

Kiến trúc E-GAS được áp dụng rộng rãi trong ngành công nghiệp ô tô nhờ vào một số ưu điểm quan trọng sau:

1. Đảm bảo an toàn đa cấp

Kiến trúc E-GAS cung cấp hệ thống giám sát độc lập ở nhiều cấp độ khác nhau, giúp giảm thiểu tác động của một lỗi đơn lẻ lên toàn bộ hệ thống. Đây là một phương pháp hiệu quả để đáp ứng các yêu cầu an toàn chức năng của các tiêu chuẩn quốc tế như ISO 26262.

2. Khả năng mở rộng và linh hoạt

Mặc dù ban đầu được phát triển cho động cơ xăng, kiến trúc E-GAS có thể áp dụng cho nhiều hệ thống và công nghệ ô tô khác nhau. Điều này cho phép hệ thống thích ứng nhanh chóng với các công nghệ và yêu cầu mới, tạo ra sự linh hoạt cao.
3. Khả năng phát hiện và đối phó với lỗi
E-GAS có cấu trúc cho phép phát hiện lỗi ở nhiều cấp độ và đưa ra các biện pháp đối phó phù hợp. Điều này giúp chuyển hệ thống sang trạng thái an toàn ngay lập tức khi phát sinh lỗi.

4. Khả năng chịu lỗi và độ bền

Với hệ thống giám sát đa cấp và hệ thống độc lập, kiến trúc E-GAS đảm bảo rằng hệ thống vẫn hoạt động mà không gặp sự cố nghiêm trọng ngay cả khi một thành phần thất bại. Khả năng chịu lỗi này giúp ô tô hoạt động ổn định trong các môi trường và điều kiện khác nhau.

5. Quản lý độ phức tạp của hệ thống

Trong bối cảnh hệ thống ô tô ngày càng phức tạp, kiến trúc E-GAS cung cấp một khung quản lý hệ thống phức tạp một cách có hệ thống. Điều này giúp cải thiện hiệu quả trong quá trình phát triển và bảo trì.

Ưu điểm Của Kiến Trúc E-gas
Ưu điểm Của Kiến Trúc E-gas

Định nghĩa Nguy hiểm (Hazard), Sự kiện nguy hiểm (Hazardous Event), Tai nạn (Accident), và Thiệt hại (Harm)

Hazard - Hazardous Event - Accident - Harm
Hazard - Hazardous Event - Accident - Harm

Nguy hiểm (Hazard), Sự kiện nguy hiểm (Hazardous Event), Tai nạn (Accident), và Thiệt hại (Harm) là các thuật ngữ thường xuất hiện trong các tiêu chuẩn an toàn liên quan đến ngành công nghiệp ô tô như ISO 26262. Những thuật ngữ này đóng vai trò quan trọng trong việc mô tả quá trình đảm bảo an toàn chức năng, vì vậy việc hiểu rõ định nghĩa của chúng là điều cần thiết.
Việc phân biệt và sử dụng đúng các thuật ngữ này cho phép thực hiện các biện pháp nhằm nâng cao an toàn chức năng trong ô tô. Bằng cách đánh giá và ngăn chặn Nguy hiểm (Hazard), ngăn chặn Sự kiện nguy hiểm (Hazardous Event) không dẫn đến Tai nạn (Accident), và giảm thiểu Thiệt hại (Harm), chúng ta có thể bảo vệ sự an toàn của người lái và hành khách, đồng thời tăng cường sự ổn định trong quá trình vận hành ô tô. Đây là cách tiếp cận cần thiết để đảm bảo an toàn trong ngành công nghiệp ô tô.

Hazard - Hazardous Event - Accident - Harm
Hazard – Hazardous Event – Accident – Harm

Nguy hiểm (Hazard)

Nguy hiểm trong ô tô là tình huống, trạng thái hoặc yếu tố tiềm ẩn khả năng gây hại cho người lái, hành khách và môi trường xung quanh. Nguy hiểm trong ô tô có thể xuất hiện dưới nhiều dạng khác nhau. Nhận biết và đánh giá những nguy hiểm này là rất quan trọng để thực hiện các biện pháp an toàn và ngăn ngừa tai nạn. Một số ví dụ bao gồm:
• Bề mặt đường trơn trượt: Đường trơn do mưa hoặc tuyết có thể gây khó khăn khi phanh.
• Lái xe khi mệt mỏi: Mệt mỏi, buồn ngủ, mất tập trung có thể làm chậm phản ứng của người lái.
• Vận tốc quá cao: Vi phạm luật giao thông hoặc lái xe với tốc độ không phù hợp với điều kiện đường sá có thể làm tăng nguy cơ tai nạn.
• Hỏng hóc cơ học: Hỏng phanh, lỗi hệ thống lái có thể gây nguy hiểm khi lái xe.

Sự kiện nguy hiểm (Hazardous Event)

Sự kiện nguy hiểm là tình huống nguy hiểm đã thực sự xảy ra. Trong ô tô, sự kiện nguy hiểm bao hàm khả năng xảy ra tai nạn. Sự kiện này có thể xảy ra bất ngờ trong quá trình lái xe và có thể dẫn đến tai nạn. Một số ví dụ bao gồm:
• Tai nạn xe: Va chạm giữa hai xe hoặc giữa xe và vật cản gây tổn thương về thể chất hoặc thiệt hại tài sản.
• Cháy xe: Tình huống nguy hiểm khi lửa bùng phát bên trong xe hoặc phần động cơ.
• Va chạm với vật cản trên không: Vật cản từ xe phía trước bật ra và gây hư hại cho xe.

Tai nạn (Accident)

Tai nạn là sự cố không mong muốn xảy ra một cách bất ngờ. Tai nạn ô tô có thể xảy ra do nhiều nguyên nhân khác nhau, chủ yếu do lỗi người lái, hỏng hóc cơ học, vi phạm tín hiệu giao thông, v.v. Tai nạn có thể gây ra thiệt hại về thể chất hoặc tài sản cho xe và hành khách. Một số ví dụ bao gồm:
• Lỗi người lái: Tai nạn do hành vi bất cẩn hoặc lái xe không đúng cách, như vượt đèn đỏ, đi sai làn, quá tốc độ.
• Hỏng hóc cơ học: Tai nạn do hỏng phanh, nổ lốp hoặc các lỗi chức năng khác của xe.
• Vi phạm tín hiệu giao thông: Tai nạn do vi phạm tín hiệu đèn hoặc quy tắc giao thông.

Thiệt hại (Harm)

Thiệt hại trong ô tô là tổn thất về thể chất, tinh thần hoặc tài sản do tai nạn hoặc tình huống nguy hiểm gây ra. Người lái và hành khách có thể bị thương, xe có thể bị hư hại, và cũng có thể xảy ra tổn thương về tinh thần. Một số ví dụ bao gồm:
• Thiệt hại về thể chất: Chấn thương, vết thương, gãy xương của người lái và hành khách.
• Thiệt hại về tài sản: Hư hại xe, tổn thất đối với xe khác hoặc tài sản.
• Thiệt hại về tinh thần: Sự lo lắng, sợ hãi, hoặc chấn thương tinh thần do tai nạn.

Thiệt Hại (harm)
Thiệt Hại (harm)

Sự khác biệt giữa OSEK RTOS và RTOS thông thường?

0
Sự Khác Biệt Giữa Osek Rtos Và Rtos
Sự Khác Biệt Giữa Osek Rtos Và Rtos

 

Bạn đã từng nghe đến thuật ngữ OSEK RTOS chưa? Nếu bạn quan tâm đến phần mềm ô tô, có lẽ bạn đã nghe qua về OSEK ít nhất một lần. Tuy nhiên, việc giải thích sự khác biệt giữa OSEK RTOS và RTOS thông thường không phải là điều dễ dàng. Trang này sẽ cung cấp một cái nhìn tổng quan về OSEK RTOS và so sánh nó với RTOS thông thường để làm rõ sự khác biệt giữa chúng.

OSEK là gì?

OSEK là viết tắt của Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen (Hệ thống Mở và Giao diện của chúng cho Điện tử trong Xe cộ). Đây là một thuật ngữ tiếng Đức và có thể khá khó phát âm. OSEK là một liên minh của Đức được thành lập để tạo ra các tiêu chuẩn phần mềm cho ECU (Electronic Control Unit) trong ô tô. Nó được thành lập vào năm 1993 bởi các công ty ô tô như BMW, DaimlerChrysler, và Volkswagen.
Ngày nay, một số tiêu chuẩn của OSEK cũng đã được đưa vào các tiêu chuẩn ISO như ISO 17456.

Sự Khác Biệt Giữa Osek Rtos Và Rtos
Sự Khác Biệt Giữa Osek Rtos Và Rtos

Sự khác biệt giữa OSEK RTOS và RTOS thông thường

OSEK RTOS và RTOS thông thường trên vi điều khiển nhìn chung cung cấp các chức năng tương tự như nhau. Ví dụ, cả hai đều có các tác vụ/luồng, mutex, semaphore, v.v. Vậy, sự khác biệt giữa chúng là gì?
OSEK RTOS thường được sử dụng trong các ứng dụng ô tô quan trọng về an toàn. Do đó, nó có những yêu cầu nghiêm ngặt hơn đối với các chức năng của RTOS. Ví dụ, OSEK RTOS chỉ cho phép cấp phát bộ nhớ tĩnh, và tất cả các tác vụ và đối tượng phải được tạo ra tại thời điểm biên dịch. Điều này khác biệt một chút so với một số hệ điều hành mã nguồn mở như FreeRTOS, nơi cho phép cấp phát bộ nhớ động.
Ngoài ra, OSEK RTOS chỉ hỗ trợ hai mức tác vụ: Basic TASK và Extended TASK. Basic TASK có thể được coi như một coroutine, được thực thi đến hoàn thành mà không bị gián đoạn. Trong khi đó, Extended TASK có thể chuyển sang trạng thái ngủ hoặc bị gián đoạn, giống như các tác vụ trong RTOS thông thường.
OSEK RTOS thường không hỗ trợ kế thừa ưu tiên. Thay vào đó, nó sử dụng priority ceilings để ngăn chặn deadlock hoặc đảo ngược ưu tiên. Lý do cho việc áp dụng chiến lược này là vì OSEK RTOS chỉ hỗ trợ các mức ưu tiên tác vụ tĩnh. Thông thường, mutex hỗ trợ kế thừa ưu tiên không có ưu tiên tĩnh.

Osek Rtos
Osek Rtos

Lập lịch trong OSEK RTOS

OSEK RTOS hỗ trợ các loại lập lịch tác vụ điển hình mà bạn có thể tìm thấy trong các RTOS thông thường. Ví dụ, bộ lập lịch có thể được cấu hình để cho phép lập lịch non-preemptive hoặc preemptive.
Trong OSEK, các tác vụ cũng có thể được nhóm lại. Các giải pháp RTOS thông thường cũng cho phép time slicing và lập lịch hợp tác cho các tác vụ ở cùng mức ưu tiên. Khả năng lập lịch của OSEK RTOS và RTOS thông thường là rất tương đồng.

Lập Lịch Trong Osek Rtos
Lập Lịch Trong Osek Rtos

Giao diện Tiêu chuẩn

Sự khác biệt lớn nhất giữa OSEK và RTOS thông thường là OSEK RTOS/OS có một bộ API và chức năng tiêu chuẩn. Giao diện này được chuẩn hóa trên tất cả các hệ điều hành OSEK RTOS.

Giao Diện Tiêu Chuẩn
Giao Diện Tiêu Chuẩn

TASK, Runnable, Process, Thread trong Hệ điều hành (OS)

0
Task, Runnable
Task, Runnable

Trong ngữ cảnh của hệ điều hành và lập trình, TASK, Runnable, Process, và Thread là những thuật ngữ biểu thị các khái niệm khác nhau.
TASK, Runnable, Process, và Thread không phụ thuộc vào một hệ điều hành cụ thể và được sử dụng trong nhiều hệ điều hành và ngôn ngữ lập trình khác nhau. Ví dụ, trong Java, có các khái niệm Runnable và Thread, trong khi trong C/C++, bạn có thể làm việc với Process và Thread. Ngay cả trong chính hệ điều hành, các khái niệm TASK và Process cũng được sử dụng để lập lịch công việc và quản lý tiến trình.
Trang này sẽ giúp chúng ta tìm hiểu về các khái niệm TASK, Runnable, Process, và Thread.

TASK, Runnable

TASK và Runnable là các khái niệm trừu tượng biểu thị các công việc có thể thực thi. TASK biểu thị đơn vị công việc trong ngữ cảnh lập trình, trong khi Runnable đóng vai trò như một giao diện để đóng gói công việc có thể thực thi. Những khái niệm này thường được sử dụng trong các ngôn ngữ lập trình và môi trường phát triển để trừu tượng hóa công việc có thể thực thi.

Task, Runnable
Task, Runnable

TASK:

Là thuật ngữ được sử dụng trong ngữ cảnh lập trình, biểu thị một công việc cụ thể cần được thực thi. Ví dụ, nó có thể là một lời gọi hàm hoặc một đơn vị thực thi để thực hiện một nhiệm vụ cụ thể. Đây là một khái niệm biểu thị một phần của logic mã mà lập trình viên đã viết.

Runnable:

Là thuật ngữ được sử dụng trong ngữ cảnh lập trình để biểu thị một công việc cụ thể cần được thực thi. “Runnable” có thể được sử dụng như một giao diện để triển khai “TASK” này. Nói cách khác, một lớp thực hiện giao diện “Runnable” có thể định nghĩa công việc có thể thực thi tương ứng với “TASK”.

Process, Thread

Process và Thread đều có thể sử dụng tính đồng thời và tính song song để thực hiện công việc. Process là một phiên bản của chương trình được thực thi ở cấp hệ điều hành (OS), mỗi process có không gian bộ nhớ độc lập và có thể chạy song song. Thread là đơn vị công việc được thực thi trong quá trình, hỗ trợ tính đồng thời bằng cách cho phép nhiều thread chạy cùng lúc.

Process, Thread
Process, Thread

Process:

Process là phiên bản của chương trình đang chạy trong hệ điều hành. Một process nhận được tài nguyên từ hệ điều hành và giữ các tài nguyên hệ thống như không gian bộ nhớ, trình xử lý tệp, và các thread. Mỗi process có một Process ID (PID) duy nhất và có không gian bộ nhớ độc lập. Các process hoạt động độc lập và được cách ly khỏi nhau.

Thread:

Thread là đơn vị công việc được thực thi bên trong một process. Một process có thể có nhiều thread, và mỗi thread có thể thực thi độc lập cùng một lúc. Các thread sử dụng tài nguyên chia sẻ (như bộ nhớ) trong process và có thể chạy đồng thời với các thread khác trong cùng một process. Threads có thể được xem là các process nhẹ và thường được sử dụng để thực hiện các tác vụ song song hoặc phân tách công việc trong cùng một process.

Tóm lại, TASK và Runnable biểu thị các công việc cần thực thi trong ngữ cảnh lập trình; Process là phiên bản của chương trình đang chạy trong hệ điều hành; và Thread là đơn vị công việc thực thi bên trong một process. Mặc dù chúng là những khái niệm khác nhau, nhưng tất cả đều đóng vai trò quan trọng trong lập trình và hệ điều hành.

Thread
Thread

Trong ngữ cảnh của TASK, khi thực thi Runnable, thực tế là nó được xử lý bên trong một Process. Runnable được thực thi thông qua Thread, hoạt động như một đơn vị thực thi trong Process. Runnable là một giao diện được sử dụng trong các ngôn ngữ lập trình như Java, đóng vai trò là một lớp bao bọc cho các công việc có thể thực thi.
Trong Java, bạn có thể định nghĩa công việc bằng cách sử dụng Runnable và truyền nó cho Thread để thực thi. Do đó, khi Runnable được thực thi, công việc tương ứng sẽ được xử lý thông qua Thread bên trong Process. Process đại diện cho một phiên bản của chương trình đang chạy, có tài nguyên và không gian bộ nhớ mà hệ điều hành cấp phát, và nó thực thi độc lập.

7 sự kiện cơ bản của CAPL

0
On Key 'key-name'()_01
On Key 'key-name'()_01

CAPL là viết tắt của Communication Access Protocol Language, một ngôn ngữ được sử dụng trong các công cụ CANoe và CANalyzer của công ty Vector. Dưới đây là 7 sự kiện cơ bản trong cú pháp CAPL. Trang này sẽ giúp chúng ta tìm hiểu về những sự kiện này.
• on start()
• on pre-start()
• on stop()
• on key ‘key-name'()
• on envvar “Envvar name”()
• on message messagename()
• on timer()

on start()

Khi nhấp vào biểu tượng hình tia sét “Measurement start” trong CANoe (hoặc CANalyzer) để bắt đầu mô phỏng, một phần mã trong hàm start() sẽ được thực thi.

On Start()
On Start()

On pre-start()

Hàm pre-start() được thực thi trước sự kiện start() và rất hữu ích cho việc khởi tạo biến, thiết lập độ trễ, và các tác vụ tương tự. setStartDelay là một chức năng độc đáo của pre-start(), có thể được sử dụng để kiểm tra các tham số thời gian.

On Pre-start()
On Pre-start()

on stop()

Sự kiện on stop() xảy ra khi nhấn nút dừng (stop) trong cửa sổ CANoe hoặc CANalyzer.

On Stop()
On Stop()

on key ‘key-name'()

Sự kiện on key ‘key-name'() xảy ra khi nhấn phím được chỉ định trong ‘key-name’.

On Key 'key-name'()
On Key ‘key-name'()
On Key 'key-name'()_01
On Key ‘key-name'()_01

on envvar “Envvar name”()

Trong CANoe, có một đối tượng gọi là biến môi trường (Env-var, Environment variable) tương tác với người dùng. Những biến môi trường này cần được tạo và định nghĩa trong tệp cơ sở dữ liệu (“.dbc” file) được liên kết với mô phỏng. Khi Env-var được liên kết thay đổi, sự kiện này sẽ được gọi.
getvalue và putvalue là các hàm đặc biệt để lấy và xác định giá trị của biến môi trường. Con trỏ “this” biểu thị env_var tại vị trí hiện tại.

On Envvar Envvar Name
On Envvar Envvar Name

on message messagename()

Sự kiện on message messagename() xảy ra khi nhận được CAN message được chỉ định trong messagename. messagename có thể được khai báo bên trong variables { } và sử dụng tại vị trí đó hoặc có thể cung cấp địa chỉ ở dạng thập lục phân.

On Message Messagename()
On Message Messagename()

on timer()

Timer là một biến đặc biệt được kích hoạt bằng cách gọi settimer() và có thể dừng lại bằng cách gọi canceltimer(). Timer có thể thực hiện công việc song song hoặc tuần tự và đóng vai trò quan trọng trong các tác vụ tự động hóa.
Timer phải được khai báo trong phần variables { }. Có hai loại biến cho timer: mstimer và timer. Khi thiết lập mstimer, giá trị được lấy theo đơn vị mili giây, và khi giá trị này hoàn tất, sự kiện on timer sẽ được thực thi. Khi thiết lập timer, sự kiện on timer xảy ra sau số giây được chỉ định trong lệnh gọi settimer.

variables
{
timer t1;
mstimer t2;
int t1delay=1;
int t2delay=1000;
}

on start()
{
settimer(t1,t1delay); // 1 sec
settimer(t2,t2delay); // 1 sec
}

on timer t1
{
write(“One second has elapsed.”);
settimer(t1,t1delay);
}

on timer t2
{
write(“1000 Milliseconds have elapsed.”);
settimer(t2,t2delay);
}

on key ‘a’
{
canceltimer(t1);
canceltimer(t2);
}

Phần mềm Mobilgene – Hyundai Motor Group

Phần Mềm Mobilgene - Hyundai Motor Group
Phần Mềm Mobilgene - Hyundai Motor Group

Hyundai Autron, công ty đã phụ trách phần mềm cơ bản (Basic S/W) cho động cơ, hộp số, và bộ điều khiển điện khí hóa của tập đoàn Hyundai Motor Group, bắt đầu với bộ điều khiển động cơ tích hợp thế hệ đầu tiên trên Elantra năm 2015. Đến năm 2016, họ đã áp dụng kiến trúc điện tử thế hệ đầu tiên cho Grandeur, nội bộ hóa và sản xuất hàng loạt nền tảng phần mềm tiêu chuẩn của Hyundai, cung cấp giao diện tiêu chuẩn cho các chức năng chung trong các lĩnh vực điện tử khác nhau.
Năm 2018, thông qua Kia K3, họ đã sản xuất hàng loạt bộ điều khiển động cơ tích hợp thế hệ thứ hai. Đến năm 2019, để nâng cao công nghệ nền tảng phần mềm cho xe tự hành và kết nối, họ đã ký hợp đồng phát triển công nghệ nền tảng phần mềm với TTTech và cùng năm đó đã ký hợp đồng cung cấp nền tảng phần mềm tiêu chuẩn cho ADAS của Hyundai.
Trước đây, đã có phần mềm cơ bản dựa trên AUTOSAR sử dụng công nghệ của TTTech và Elektrobit, nhưng Hyundai Autoever đã nội bộ hóa và xây dựng thương hiệu thành Mobilgene.

Mobilgene Classic

Mobilgene Classic là phần mềm cơ bản dựa trên AUTOSAR Classic do Hyundai Autoever phát triển cùng với bộ phận nghiên cứu và phát triển của Hyundai, Kia, và Hyundai Mobis. Đây có thể được xem là dòng sản phẩm Mobilgene dành cho các bộ điều khiển dựa trên MCU.

Phần Mềm Mobilgene - Hyundai Motor Group
Phần Mềm Mobilgene – Hyundai Motor Group

Mobilgene Classic, được triển khai nhằm chuẩn hóa phần mềm cơ bản (Basic S/W) vốn khác nhau giữa các bộ điều khiển chính của xe, tính đến năm 2020 đã dẫn đầu với hơn 130 dự án trong lĩnh vực tiện nghi điện tử (Electronic Convenience). Hiện tại, Mobilgene Classic đang được sử dụng rộng rãi trong lĩnh vực ADAS và tiếp tục mở rộng áp dụng sang các lĩnh vực khác như xe thương mại, xe thân thiện với môi trường, bao gồm cả hệ thống SBW vào năm 2020 và Air Suspension vào năm 2021, mở rộng sang lĩnh vực khung gầm (chassis).

Mobilgene Classic
Mobilgene Classic

Dòng sản phẩm Mobilgene Classic bao gồm Classic v.4.0.3 và Classic v.4.4.0, được ra mắt vào nửa cuối năm ngoái. Classic v.4.0.3 hiện là sản phẩm chủ lực đang được sản xuất hàng loạt, được sử dụng rộng rãi trong các bộ điều khiển yêu cầu hiệu suất tương đối trung cấp trở xuống, như SBW và ACU, và hỗ trợ khoảng 70 mô-đun.
Classic v.4.4.0, ra mắt vào nửa cuối năm ngoái, tập trung vào việc phát triển 57 mô-đun nền tảng AR44, phân phối đa lõi (Multicore BSW), và đảm bảo an toàn chức năng. Trước đây, trong các phiên bản AUTOSAR cũ, BSW phải được đặt trong một phân vùng duy nhất, nhưng giờ đã được phân phối. Điều này cho phép, ví dụ, phân phối CAN vào một lõi và Ethernet vào một lõi khác, nâng cao hiệu suất hỗ trợ hoạt động độc lập.
Ngoài ra, so với phiên bản v4.0.3 chưa đạt được chứng nhận ASIL, Classic v.4.4.0 đã tăng cường an toàn chức năng (Functional Safety), đồng thời đạt được chứng nhận ASIL-D và ISO26262. Nó cũng hỗ trợ các MCU Infineon TC38X và TC39X, dự kiến sẽ được sử dụng rộng rãi trong các bộ điều khiển yêu cầu hiệu suất cao hơn như ADAS, Connectivity, và Infotainment.

Mobilgene Classic Bao Gồm Classic V.4.0.3 Và Classic V.4.4.0
Mobilgene Classic Bao Gồm Classic V.4.0.3 Và Classic V.4.4.0

Mobilgene AD

Mobilgene AD là phần mềm cơ bản (Basic S/W) dành riêng cho ADAS, không tuân theo tiêu chuẩn, được phát triển để đối phó với giai đoạn chuyển tiếp giữa việc ra mắt Classic và Adaptive. Đây là sản phẩm đầu tiên mang lại doanh thu thực tế trên mỗi chiếc xe, với doanh thu dự kiến từ 40,000 đến 50,000 won cho mỗi xe hỗ trợ hai chức năng (tự lái từng phần và tự đỗ xe), và từ 20,000 đến 30,000 won cho mỗi xe chỉ hỗ trợ một chức năng.
Bắt đầu với mẫu Genesis G90 và GV60 mới, số lượng mẫu xe được trang bị Mobilgene AD dự kiến sẽ tăng lên khoảng 20 chiếc vào năm 2025. Về phần mềm trung gian (Middleware), dự kiến tích hợp chức năng Sync của TTTech, và hệ điều hành sẽ sử dụng Blackberry QNX. Hyundai đã cân nhắc giữa NVIDIA Xavier và Intel Denverton cho bộ xử lý ADAS, nhưng cuối cùng đã chọn Intel Denverton do khả năng đảm bảo nguồn cung dễ dàng hơn và tính cạnh tranh về giá.

Mobilgene Ad
Mobilgene Ad
Mobilgene Ad_01
Mobilgene Ad_01

Mobilgene Adaptive

Cùng với cập nhật qua mạng (OTA Update), SOA Ethernet, và CAN Gateway là những đặc điểm kỹ thuật chính của Mobilgene Adaptive. Khác với Classic vốn tập trung vào các bộ điều khiển dựa trên MCU, Mobilgene Adaptive là phần mềm cơ bản dựa trên AUTOSAR Adaptive cung cấp môi trường cho các bộ xử lý ứng dụng (AP) hiệu suất cao và nhiều ứng dụng khác nhau. Do đó, nó dự kiến sẽ được áp dụng cho các ECU hiệu suất cao như hệ thống thông tin giải trí (Infotainment), ADAS, và Connectivity.
Năm 2018, Hyundai Autron đã bắt tay hợp tác phát triển với WindRiver, với thỏa thuận chia sẻ quyền sở hữu trí tuệ và kết quả phát triển chung. Tại CES 2020, một nguyên mẫu sử dụng chipset của NXP Semiconductor đã được trưng bày. Hiện tại, việc phát triển kỹ thuật dựa trên AUTOSAR Adaptive Release 19-11 đang được tiến hành, nhằm mục tiêu ứng dụng sản xuất hàng loạt vào khoảng năm 2024-2025, tương tự thời điểm với DRV3. Do đó, các thông tin kỹ thuật chính xác liên quan đến Mobilgene Adaptive vẫn còn khó xác định.
Tuy nhiên, dự kiến sẽ có một cấu trúc trong đó Connectivity Control Unit đóng vai trò chính, truyền tải thông tin từ các camera Ethernet và các bộ điều khiển khác cũng như tín hiệu CAN đến phần mềm ứng dụng thông qua Adaptive.
Một điểm khác biệt khác giữa AUTOSAR Classic và Adaptive là sự hiện diện của hệ điều hành (OS). Để thực hiện POSIX, Blackberry QNX hoặc hệ điều hành dựa trên Linux thường được sử dụng. Hiện tại, hệ điều hành vẫn chưa được xác định.
Mobilgene Adaptive, dự kiến ra mắt vào năm 2024-2025, sẽ được tích hợp vào các mẫu xe chính của Hyundai và Kia thông qua các linh kiện điều khiển từ các nhà cung cấp chính trong tập đoàn Hyundai Motor Group như Hyundai Mobis và Hyundai Kefico. (Phần mềm ứng dụng điều khiển sẽ do Hyundai Mobis, Mando, và các công ty khác đảm nhận).

Mobilgene Adaptive & Classic
Mobilgene Adaptive & Classic

Mobilgene Classic & Mobilgene Adaptive

AUTOSAR Classic được sử dụng trong các hệ thống nhúng nhỏ như thân xe và khung gầm, nơi phản hồi thời gian thực là quan trọng. Ngược lại, AUTOSAR Adaptive dự kiến sẽ được sử dụng rộng rãi trong tương lai cho các công nghệ như ADAS và V2X, nơi tính kết nối và hỗ trợ phần cứng hiệu suất cao là cần thiết. Vì vậy, thay vì Mobilgene Adaptive thay thế hoàn toàn Mobilgene Classic, dự kiến cả hai dòng sản phẩm này sẽ được sử dụng bổ trợ lẫn nhau.
Khi kiến trúc E/E của ô tô trong tương lai chuyển sang dạng tập trung, một đơn vị máy tính trung tâm hiệu suất cao sẽ đóng vai trò trung tâm. Để vận hành bộ vi xử lý hiệu suất cao, sẽ cần hệ điều hành 64-bit. Tiêu chuẩn AUTOSAR Adaptive dựa trên hệ điều hành 64-bit (tương ứng với Mobilgene Adaptive) sẽ đóng vai trò là nền tảng AUTOSAR thế hệ tiếp theo.
Trong mỗi miền (Domain), sẽ có một Domain Controller Unit, và bên dưới đó sẽ là các bộ điều khiển như cảm biến và bộ chấp hành hiện có sử dụng MCU 32-bit. Vì AUTOSAR Classic vẫn sẽ hỗ trợ MCU 32-bit, dự kiến Mobilgene Classic và Mobilgene Adaptive sẽ được sử dụng song song như những sản phẩm bổ sung lẫn nhau, thay vì thay thế nhau trong một thời gian dài.

Mobilgene Classic Và Mobilgene Adaptive
Mobilgene Classic Và Mobilgene Adaptive

Autosar Basic Software – AUTOSAR BSW – Basic Software

0
Autosar Basic Software
Autosar Basic Software

AUTOSAR là một kiến trúc tiêu chuẩn hóa cho phần mềm và hệ thống trên xe hơi, đóng vai trò ngày càng quan trọng trong ngành công nghiệp ô tô. AUTOSAR BSW (Basic Software) là một trong những thành phần cốt lõi của kiến trúc này, hỗ trợ tương tác trơn tru giữa các mô-đun phần cứng và phần mềm khác nhau.
Trang này sẽ giới thiệu tổng quan về AUTOSAR BSW, các mô-đun chính của nó, vai trò của nó trong hệ thống, và cách thức cấu thành của nó

Autosar Basic Software
Autosar Basic Software

AUTOSAR BSW (Basic Software)

AUTOSAR BSW (Basic Software) là một phần cốt lõi của kiến trúc AUTOSAR, cung cấp các dịch vụ và giao diện cơ bản để đảm bảo các phần cứng khác nhau và phần mềm ứng dụng trên xe hơi hoạt động một cách mượt mà. Điều này cho phép các nhà phát triển phần mềm ô tô xây dựng và quản lý hệ thống hiệu quả hơn mà không phụ thuộc vào phần cứng.

• Trừu tượng hóa phần cứng: Quản lý các thành phần phần cứng khác nhau thông qua một giao diện chung, giúp giảm thiểu việc phải sửa đổi phần mềm khi thay đổi phần cứng.
• Ngăn xếp giao tiếp: Quản lý các giao thức và dịch vụ cho việc truyền thông dữ liệu.
• Hệ điều hành (OS): Cung cấp các dịch vụ cơ bản ở cấp độ hệ điều hành, như lập lịch tác vụ và xử lý ngắt.

Các Thành Phần Của Bsw - Autosar Bsw
Các Thành Phần Của Bsw – Autosar Bsw

Các thành phần của BSW

Các thành phần sau đây tương tác với nhau, đảm bảo hoạt động ổn định ngay cả trong các hệ thống ô tô phức tạp. BSW tích hợp các mô-đun và dịch vụ này để đóng vai trò như một nền tảng hỗ trợ các chức năng và dịch vụ đa dạng của ô tô.

1. MCU (Microcontroller Unit)

o Chịu trách nhiệm khởi tạo, cấu hình, và quản lý cơ bản của vi điều khiển.
o Chức năng chính: Khởi tạo phần cứng, quản lý xung nhịp, xác định nguyên nhân reset, v.v.

2. ECU Abstraction Layer

o Cung cấp một lớp trừu tượng giữa phần cứng và BSW để giảm sự phụ thuộc vào phần cứng.
o Chức năng chính: Xử lý I/O, cung cấp các trình điều khiển như ADC, PWM, v.v.

3. Service Layer

o Cung cấp các dịch vụ và thuật toán cơ bản.
o Chức năng chính: Dịch vụ chẩn đoán, mã hóa, nén dữ liệu, dịch vụ bộ nhớ, v.v.
4. Com Stack
o Hỗ trợ nhiều giao thức truyền thông khác nhau.
o Chức năng chính: Gửi và nhận tin nhắn, quản lý trạng thái truyền thông, quản lý bus, v.v.
o Giao thức hỗ trợ: CAN, LIN, Ethernet, FlexRay, v.v.

5. OS (Operating System)

o Quản lý hoạt động của hệ thống và cung cấp các dịch vụ hệ điều hành đa dạng.
o Chức năng chính: Lập lịch tác vụ, quản lý ngắt, xử lý sự kiện, quản lý tài nguyên, v.v.

6. Memory Management

o Quản lý việc sử dụng bộ nhớ một cách hiệu quả.
o Chức năng chính: Cấp phát và giải phóng bộ nhớ, bảo vệ bộ nhớ, quản lý bộ nhớ liên tục.

7. NVRAM Manager

o Quản lý bộ nhớ không bay hơi một cách hiệu quả.
o Chức năng chính: Lưu trữ và khôi phục dữ liệu, sắp xếp và tối ưu hóa bộ nhớ.

- Advertisement -
Autosar Eio Group

Bài viết gần đây