🌱 AUTOSAR Notes. Các thuật ngữ chung trong AUTOSAR

🌱 AUTOSAR Notes: Các thuật ngữ chung trong AUTOSAR

AUTOSAR logo

    AUTOSAR được xây dựng để tiêu chuẩn hóa việc phát triển phần mềm cho các ECU trong các ứng dụng Automotive. Do đó, có nhiều thuật ngữ mà có thể những người học nhúng thông thường chưa nghe đến bao giờ. Trong chuỗi bài viết về AUTOSAR, mình sẽ sử dụng lặp lại các thuật ngữ này và nó cũng có thể xuất hiện trong rất nhiều tài liệu khác nữa về AUTOSAR! Vì vậy, trong bài viết này và cả series, mình sẽ giữ các thuật ngữ ở dạng tiếng anh để tránh sai lệch về mặt ý nghĩa.

Nội dung bài viết

👉 Integrator

    Với Autosar, khái niệm Integrator là cấu hình và tạo dự án AUTOSAR bằng giao diện phần mềm, bằng các phần mềm GUI cấu hình bộ config như đã giới thiệu trước đây. Trong dự án AUTOSAR, developer triển khai SWC bằng cách viết code Runnable.

👉 Signal

    AUTOSAR thực hiện giao tiếp dựa trên các signal. Signal là định lượng thông tin nhỏ nhất mà một bản tin CAN có thể có. Một Signal có thể có bất kỳ kích thước nào từ 1 đến 64 bits, tùy thuộc vào bản tin CAN. Khái niệm Signal cũng có thể sử dụng cho FlexRay và các Bus khác, chỉ khác ở chỗ số lượng bit tối đa của nó.

    Một ví dụ thực tế, giả sử một ECU cần biết trạng thái của cửa (locked/un-locked). Trong một chương trình C, chúng ta có thể triển khai một biến cờ (Flag) để hiển thị trạng thái của cửa. Trong AUTOSAR, chỉ cần tín hiệu 1 bit được sử dụng để biểu thị điều này.

AUTOSAR Signal
AUTOSAR Signal Example

    Tương ứng với các tín hiệu có kích thước lớn hơn, giả sử rải giá trị từ 0-7 sẽ cần 3 bit để hiển thị.

    ➤ Cách làm này giúp tiết kiệm tối đa không gian bộ nhớ.

    SWC sử dụng Signal để giao tiếp với nhau bằng cách sử dụng VFB-Virtual Function Bus qua tầng RTE. Signal được triển khai và chỉ được hiểu bởi các layer từ COM đến Application.

    Các signal có thể được nhóm khi chúng cần được giữ mối liên hệ với nhau, hoặc nhóm với nhau thành một struct. Ví dụ như struct gồm các bits của một thanh ghi.

👉 PDU / Message

    Trong AUTOSAR, một message có thể được gọi là PDU (Protocol Data Unit). PDU chứa thông tin khác với dữ liệu được sử dụng hoặc trích xuất bởi các lớp dưới hoặc lớp trên trong quá trình truyền/nhận. Có thể có n số PDU với kích thước khác nhau. Về cơ bản, PDU là một nhóm các Signal được đóng gói cùng với thông tin lớp thấp hơn.

    AUTOSAR COM thực hiện đóng gói hoặc giải nén tín hiệu vào hoặc từ PDU trong khi truyền/nhận. Mỗi PDU có một ID duy nhất.

    PDU chứa SDU (Service Data Unit) và PCI (Protocol Control Information).

  • SDU là dữ liệu cần được truyền đi. Trong khi truyền, SDU được truyền từ các lớp trên xuống lớp dưới cùng với PCI. Trong quá trình nhận, SDU là dữ liệu được trích xuất từ các lớp dưới và được chuyển lên các lớp trên.
  • PCI chứa thông tin cho biết điểm đến tiếp theo của SDU. Về cơ bản, nó chứa thông tin nguồn và đích của SDU, trong trường hợp này là lớp tiếp theo mà PDU cần được chuyển đến.

    ➤ Nói đơn giản, PDU được chuyển từ các lớp trên xuống lớp dưới và ngược lại, nơi chứa SDU và PCI.

PDU_SDU_PCI
Việc đóng gói SDU và PCI trong một PDU khi truyền từ lớp cao xuống lớp thấp hơn

    Việc truyền PDU từ lớp này sang lớp khác được gọi bằng tên có liên quan đến lớp mà nó nằm trong đó. Ví dụ I-PDU (Interaction Layer PDU), N-PDU (Network Layer PDU), L-PDU (Data Link Layer PDU).

👉 Computation Methods

    Compu Methods được sử dụng để chuyển đổi các giá trị cố định trong phần mềm thành các giá trị vật lý có thể là giá trị dấu phẩy động.

    Compu Methods xác định mối quan hệ chuyển đổi các giá trị bên trong của SWC thành giá trị vật lý. Compu Methods được định nghĩa cho một Signal.

    Có 3 loại Compu Methods chính:

  • Linear - Tuyến tính. Sử dụng khi giá trị được chuyển đổi thuộc loại tuyến tính. Trong quá trình cấu hình, cần phải đưa ra phạm vi giá trị thô (Min và Max của giá trị, Gain, Offset Value).
  • Text Table. Đây là Compu Methods đơn giản nhất. Nó là một bảng các giá trị số đại diện cho một số văn bản có ý nghĩa nào đó.
  • Scale-Linear. Đây là một bảng các Compu Methods kiểu Linear.

👉 .cdd file

    File này không liên quan gì đến tầng CDD đã từng nói ở các bài trước 😅

    .cdd file là file cụ thể của Vector chứa thông tin liên quan đến cấu hình Diagnostics configuration. Mặc dù nó khá specific nhưng nhiều tool/ide vẫn dùng nó làm tiêu chuẩn.

👉 OSEK/VDX

    Thuật ngữ này là viết tắt của một từ tiếng Đức hơi dài chút (Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen), và có thể hiểu đơn giản theo tiếng anh là Open Systems and their Interfaces for the Electronics in Motor Vehicles. Nó cung cấp một số đặc điểm kỹ thuật của hệ điều hành (OS), communication stack, và giao thức quản lý mạng được sử dụng trong các ứng dụng ô tô, được triển khai bởi một tập đoàn gộp nhiều công ty ô tô lớn của Đức như BMW, Bosch, Opel, Siemens, Volkswagen.

    Dự án này sau đó có sự tham gia của một số công ty ô tô của Pháp như RenaultPSA Peugeot, những công ty có dự án tương tự gọi là VDX (Vehicle Distributed Executive). Vì vậy, cái tên OSEK/VDX được sử dụng kết hợp.

👉 Composition SWC

    Composition là một nhóm các Software Component (SWC), được gán cho một ECU duy nhất trong System Configuration, tức là ECU này sẽ đảm nhiệm một số chức năng (của từng SWC) trong application. Việc phân nhóm này giúp trừu tượng hóa các Software Component và tiêu chuẩn hóa quá trình phát triển phần mềm, đó là điều mà AUTOSAR hướng tới.

👉 SWC

    Trong AUTOSAR, application được phân phối trong các SWC khác nhau. SWC - Software Component là một thành phần có logic ứng dụng, trong AUTOSAR, một chức năng sẽ được đóng gói bởi SWC.

    Ví dụ. Hoạt động cửa cửa sổ điện trên ô tô, một SWC chuyên dụng sẽ được đóng gói để thực hiện chức năng này.

    Các SWC giao tiếp với nhau, hoặc sử dụng các lớp thấp hơn bằng cách sử dụng các Ports, với sự trợ giúp của RTE.

    ➤ AUTOSAR phân loại SWC dựa trên công dụng của nó:

  • Application SWC.
  • SensorActuator SWC. Xử lý các Cảm biến và thiết bị chấp hành.
  • Parameter SWC. Sử dụng để chia sẻ các tham số hiệu chuẩn của ECU với các thiết bị bên ngoài.
  • Composition SWC. Đã nói ở trên.
  • Service Proxy SWC. Hoạt động như một proxy, cung cấp dịch vụ nội bộ cho một hoặc nhiều ECU từ xa, phân phối thông tin chế độ hoạt động của xe cho toàn bộ hệ thống.
  • Service SWC. Cung cấp các dịch vụ AUTOSAR cụ thể của module BSW.
  • ECU Abstraction SWC. Cung cấp quyền truy cập vào các I/O bằng cách tương tác trực tiếp với các module BSW cụ thể (Chỉ có thể sử dụng SWC này để truy cập I/O).
  • Complex Device Driver SWC. Được sử dụng để phát triển CDD cho các thiết bị bên ngoài mà AUTOSAR không hỗ trợ, hoặc một số hoạt động quan trọng.
  • Nvblock SWC. Tương tác với NVRAM hoặc memory.

👉 Runnable Entity

    Runnable Entity là một thành phần của SWC, nơi viết các logic hành vi của tầng Application. Có thể hiểu Runnable tương tự các function trong C. Trong AUTOSAR, Runnable được tạo ra trong một SWC trong quá trình config, và Runnable hay function đó được tạo ra trong các file source code của SWC.

    Tên của function được người dùng cấu hình trong giao diện cấu hình, và sẽ được thực thi bởi AUTOSAR OS. Người dùng sẽ cần viết nội dung của các function này. Các function này có thể sử dụng khái niệm "Trigger Point" - tức là hàm sẽ được gọi khi thỏa mãn một số điều kiện nhất định.

Composition SWC and Runnables
Composition SWC and Runnables

    ➤ Có 3 loại Runnable:

  • Init Runnable. Được gọi khi khởi tạo ECU.
  • Periodic Runnable. Sử dụng khi cần trigger function này để thực thi một số hoạt động một cách có chu kỳ.
  • Server Runnable. Sử dụng để triển khai server của giao diện port client/server.

    Runnable có thể được cấu hình để hoạt động trên các sự kiện RTE như:

  • Timing Event. Như giải thích ở trên, bất cứ khi nào đạt đến thời gian đã set từ trước, một sự kiện sẽ kích hoạt Periodic Runnable. Việc này có thể triển khai bằng các ngắt Timer.
  • Data Received Event. Sự kiện được kích hoạt khi có data được nhận bởi Ports.
  • Operation Invoked Event. Sự kiện được gọi bởi Client khi một Server có thể chạy được bằng
  • Mode Switch Event. Bất cứ khi nào chế độ hoạt động của ECU thay đổi, Runnable có thể được trigger để hoạt động. Ví dụ. ECU ở chế độ shutdown, nếu ECU cần thực hiện một số hoạt động trước khi shutdown, sự kiện đó sẽ được nối với Runnable và thực hiện trước khi shutdown.
  • Data Received Error Event. Xảy ra khi có bất kỳ lỗi xảy ra trong quá trình nhận dữ liệu.
  • Data Send Completed Event. Runnable được trigger khi dữ liệu được gửi thành công.

👉 File MemMap

    Phần này khá hay và dài nên mình sẽ giới thiệu riêng ở bài sau.

👉 Port and Port Interfaces

    Trong AUTOSAR, mọi giao tiếp giữa SWC với các lớp thấp hơn được thực hiện bằng cách sử dụng Ports. Port là một channel hoặc connection sử dụng truyền nhận data giữa các SWC, hoặc các module BSW.

    Như mục đích của AUTOSAR là tiêu chuẩn hóa, data sẽ được truyền nhận giữa các thực thể cần được biết đến tại thời điểm cấu hình, Port cũng không phải ngoại lệ.

    Các Port thuộc về một SWC tại mỗi thời điểm. Port có thể hoặc không được kết nối với mỗi đầu. Có 2 loại Port:

  • Required Port. Sử dụng khi dữ liệu được nhận hoặc được yêu cầu từ các thực thể khác.
  • Provider Port. Sử dụng khi dữ liệu được truyền hoặc SWC là nơi cung cấp các dịch vụ đến các thực thể khác.

    Port Interfaces là giao diện định nghĩa loại thông tin được truyền nhận giữa 2 Ports. Port Interfaces định nghĩa một protocol tuân theo port của SWC. Port Interface có thể được tái sử dụng bởi nhiều port khác nhau.

    Port Interface được cấu hình tại thời điểm system configuration và port sẽ hoạt động theo port interface được cấu hình tại thời điểm đó.

    ➤ AUTOSAR có 3 loại Port Interfaces:

  • AUTOSAR Interface. Một giao diện chung được tạo cho các Port của SWC, sử dụng để tương tác với các SWC khác, hoặc ECU Abstraction Layer.
  • Standardized AUTOSAR Interface. Giao diện này được AUTOSAR định nghĩa trước, được ứng dụng SWC sử dụng khi tương tác với các BSW Services như ECU Manager, ...
  • Standardized Interface. Giao diện này cũng được định nghĩa trước bởi AUTOSAR, nó giống như các API C, sử dụng giữa các module BSW, giữa RTE và OS, ...

👉 Hardware Objects / Hardware Object Handle

    Thuật ngữ Hardware Object được sử dụng liên quan đến CAN Bus, nó là một vùng nhớ thuộc RAM của CAN Controller, nơi chứa PDU. Khi PDU nằm trong RAM của CAN Controller, nó được gọi là Harware Object.

    HOH - Hardware Object Handle đại diện cho một tham chiếu trừu tượng của CAN Mailbox, nơi có tất cả tham số của CAN Frame như DLC, CANID, CAN Data. Các lớp trên không thể trực tiếp tạo ra CAN Frame với data và điều này mâu thuẫn với mục tiêu độc lập phần cứng của AUTOSAR, thay vào đó, một tham chiếu trừu tượng được sử dụng để đảm bảo sự độc lập phần cứng này.

    Có 2 loại HOH:

  • HTH - Hardware Transmit Handle. Sử dụng trong quá trình truyền của CAN Frame.
  • HRH - Hardware Receive Handle. Sử dụng trong quá trình nhận của CAN Frame.

    HOH được sử dụng bởi CanIf và được tham chiếu dựa trên bộ đệm phần cứng CAN. HOH được sử dụng làm parameter khi gọi tầng thấp hơn - CAN Driver.

Hardware Object Handle references in different modules
Hardware Object Handle references in different modules

    Trên đây là một số khái niệm/thuật ngữ cơ bản trong AUTOSAR mà mình tìm hiểu được, thực tế còn rất nhiều thuật ngữ khác nữa. Nhưng trong phạm vi bài viết có giới hạn nên chỉ giới thiệu được những thuật ngữ chính và có thể chưa dễ hiểu lắm. Các bạn có thể search các keyword trên Internet để có thể tìm hiểu sâu hơn.

>>>>>>>> Follow ngay <<<<<<<<

Để nhận được những bài học miễn phí mới nhất nhé

Chúc các bạn học tập tốt 😊

Nguyễn Văn Nghĩa

Mình là một người thích học hỏi và chia sẻ các kiến thức về Nhúng IOT.

Đăng nhận xét

Mới hơn Cũ hơn