Các Thuật Ngữ AUTOSAR
Các thuật ngữ AUTOSAR được xây dựng để chuẩn hóa việc phát triển phần mềm của ECU. Do đó nó có nhiều thuật ngữ mà chúng ta có thể chưa bao giờ nghe nói đến. Bài viết này thảo luận về một số thuật ngữ phổ biến được sử dụng trong AUTOSAR và giải thích chúng.
+ Integrator
Trong bối cảnh AUTOSAR, nhà tích hợp là người định cấu hình và tạo dự án AUTOSAR bằng phần mềm GUI như Vector DaVinci. Chúng tôi thường tự gọi mình là nhà phát triển vì chúng tôi phát triển phần mềm, nhưng trong dự án AUTOSAR, nhà phát triển là người thực hiện hành vi của SWC bằng cách viết mã trong Runnable .
+ Signal
AUTOSAR thực hiện giao tiếp dựa trên tín hiệu. Tín hiệu là lượng thông tin nhỏ nhất mà một bản tin CAN có thể có. Một tín hiệu có thể có kích thước bất kỳ từ 1 bit đến tất cả 64 bit của bản tin CAN (coi bản tin CAN là 8 Byte), nói cách khác, bản tin CAN được chia thành các bit được gọi là tín hiệu. Tín hiệu cũng có thể ở đó cho FlexRay hoặc xe buýt khác, thay đổi duy nhất là lượng tín hiệu tối đa mà nó có thể giữ.
Để liên hệ điều này, chúng ta hãy xem xét một ví dụ thực tế trong cuộc sống. Giả sử một ECU cần biết trạng thái của các cửa (đã khóa/mở khóa). Trong chương trình C bình thường, chúng tôi sẽ triển khai một cờ cho biết trạng thái của các cửa. Nhưng trong AUTOSAR, tín hiệu 1 bit được sử dụng để biểu thị điều này. Hình ảnh bên dưới hiển thị tín hiệu của chúng tôi trong trường Dữ liệu CAN của khung.
Từ hình trên, chúng ta có thể thấy rằng thông tin của chúng ta chỉ yêu cầu kích thước 1 bit. Một tín hiệu có thể có kích thước bất kỳ tùy thuộc vào yêu cầu. Giả sử ứng dụng của bạn cần truyền thông tin số trong phạm vi từ 0 – 7 , vì vậy tín hiệu 3 bit là đủ. Theo cách này, việc triển khai tín hiệu giúp tiết kiệm không gian theo yêu cầu của thông tin trong trường dữ liệu CAN bằng cách chỉ sử dụng không gian cần thiết cho thông tin.
SWC sử dụng tín hiệu để liên lạc với nhau bằng cách sử dụng VFB qua RTE . Tín hiệu được triển khai và chỉ được hiểu bởi các lớp từ COM đến Lớp ứng dụng.
Các tín hiệu có thể được nhóm khi các tín hiệu cần được giữ chặt chẽ với nhau hoặc các nhóm tín hiệu có thể được sử dụng để hỗ trợ cấu trúc dữ liệu phức tạp như cấu trúc . Trong mã, một cấu trúc sẽ được triển khai có các thành viên là tín hiệu không gì khác ngoài nhóm tín hiệu.
+ PDU Or Message:
Trong AUTOSAR, đại khái một thông báo được gọi là PDU (Đơn vị dữ liệu giao thức). Tôi đang nói đại khái là bởi vì, PDU chứa thông tin khác với dữ liệu của chúng tôi được sử dụng hoặc trích xuất bởi các lớp bên dưới hoặc bên trên trong quá trình truyền hoặc nhận tương ứng. Có thể có n số PDU với kích thước khác nhau. PDU về cơ bản là nhóm các tín hiệu đượ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 hoặc nhận tương ứng. Mỗi PDU có một mã định danh duy nhất được liên kết với nó.
PDU chứa SDU và PCI. SDU là chữ viết tắt của Service Data Unit và PCI là 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 các 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 bên 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 nguồn và đích của SDU. Nguồn và đích trong trường hợp này là lớp tiếp theo mà PDU cần được chuyển đến.
Nói một cách đơ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. Hình dưới đây sẽ giúp hiểu điều này.
Trong khi chuyển PDU từ lớp này sang lớp khác, nó được gọi bằng các tên có liên quan dựa trên lớp mà nó nằm trong đó. Các PDU được đặt tên là: I-PDU (PDU lớp tương tác), N-PDU (PDU lớp mạng), L-PDU (Lớp liên kết dữ liệu) PDU).
Bất cứ khi nào PDU ở các lớp trên lớp Trừu tượng phần cứng giao tiếp thì nó được gọi là I-PDU. Bất cứ khi nào PDU ở các lớp bên dưới PDUR và trên lớp Trình điều khiển giao tiếp thì nó được gọi là N-PDU . Bất cứ khi nào PDU ở bên dưới Trừu tượng hóa phần cứng giao tiếp thì nó được gọi là L-PDU.
+ Computation Method:
Phương pháp tính toán hay nói ngắn gọn là phương pháp tính toán được sử dụng để chuyển đổi các giá trị điểm 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.
Phương thức tính toán xác định mối quan hệ chuyển đổi các giá trị bên trong của SWC thành giá trị thực/vật lý. Phương pháp tính toán được xác định cho một tín hiệu.
Chủ yếu có ba loại phương pháp tính toán:
+ Linear:
Loại phương thức Compu này được 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, chúng tôi phải đưa ra phạm vi giá trị thô. Giống như giá trị tối thiểu này có thể là, giá trị tối đa này có thể đi, Hệ số (là hệ số nhân hay còn gọi là mức tăng), Giá trị bù.
+ Text Table:
Đây là loại phương thức tính toán đơn giản nhất. Đó 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 phương thức tính toán tuyến tính.
+ .Cdd File:
Tệp .cdd là tệp cụ thể của Vector chứa thông tin liên quan đến cấu hình Chẩn đoán. Mặc dù nó là véc tơ cụ thể nhưng nhiều công cụ đang sử dụng nó làm tiêu chuẩn . Tệp này được sử dụng trong ứng dụng CandelaStudio bằng Vector. Không nên nhầm lẫn điều này với Trình điều khiển thiết bị phức tạp ( CDD ) 😀, tôi đã bối rối khi nghe thuật ngữ này lần đầu tiên!
+ SIP:
SIP hoặc S oftware I n P package là một thuật ngữ được các kỹ sư AUTOSAR sử dụng Công cụ Vector DaVinci . Nó là một gói chứa tất cả các thư viện và tệp hữu ích để phát triển phần mềm AUTOSAR bằng các công cụ Vector.
+ OSEK/VDX:
Thuật ngữ này cũng thường được nghe từ các kỹ sư AUTOSAR. OSEK là chữ viết tắt của O flene S ysteme und deren Schnittstellen für die E lektronik in K bèfahrzeugen trong tiếng Đức nhưng trong tiếng Anh, nó là: Hệ thống mở và giao diện của chúng cho thiết bị điện tử trong xe cơ giới. Nó cũng là một đặc điểm kỹ thuật của hệ điều hành, ngăn xếp truyền thông và giao thức quản lý mạng được sử dụng trong các ứng dụng Ô tô được phát triển bởi một tập đoàn gồm các công ty ô tô Đức như BMW , Robert Bosch GmbH , DaimlerChrysler , Opel , Siemens và Tập đoàn Volkswagen và Tập đoàn Volkswagen.Đại học Karlsruhe . Dự án này sau đó được tham gia bởi các công ty ô tô của Pháp như Renault và PSA Peugeot Citroën , những công ty có dự án tương tự được gọi là VDX (Vehicle Distributed Executive). Do đó, tên OSEK/VDX được sử dụng kết hợp.
+ Composition SWC:
Thành phần không là gì ngoài một nhóm SWC được gán cho một ECU duy nhất trong Cấu hình hệ thống . Việc phân nhóm như vậy giúp trừu tượng hóa các SWC 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. Việc phân nhóm này là hợp lý, có nghĩa là không có bộ nhớ nào được sử dụng trong cách phân nhóm đó.
+ SWC:
Trong AUTOSAR, ứng dụng được phân phối trong các SWC khác nhau. SWC hoặc thành phần phần mềm là một thành phần có logic ứng dụng. Trong AUTOSAR, một chức năng được đóng gói bởi SWC. Ví dụ: hoạt động của cửa sổ điện trong ô tô, một SWC chuyên dụng sẽ 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 cổng với sự trợ giúp của RTE .
AUTOSAR đã phân loại SWC dựa trên việc sử dụng nó thành các loại sau:
1. Ứng dụng SWC: Đây là SWC bình thường chỉ có ứng dụng hoặc một phần của nó.
2. Bộ truyền động cảm biến SWC: Đây là một loại SWC đặc biệt xử lý các cảm biến hoặc bộ truyền động.
3. Tham số SWC: SWC này được sử dụng để chia sẻ các tham số hiệu chuẩn của (ECU mà nó được đặt) với các thiết bị bên ngoài. Các SWC này không có bất kỳ hành vi nội bộ nào không giống như SWC ứng dụng hoặc SWC cảm biến.
4. Thành phần SWC: đã thảo luận ở trên .
5. Service Proxy SWC: Nó hoạt động như một proxy để cung cấp các dịch vụ nội bộ cho một hoặc nhiều ECU từ xa. Công dụng chính của nó là phân phối thông tin chế độ của xe trên toàn hệ thống.
6. Dịch vụ SWC: Nó cung cấp các dịch vụ được chỉ định bởi AUTOSAR của mô-đun BSW .
7. ECU trừu tượng SWC: Loại SWC này cung cấp quyền truy cập vào I/O bằng cách tương tác trực tiếp với các mô-đun BSW cụ thể. Không thể sử dụng các SWC khác để truy cập I/O, chỉ có thể sử dụng SWC này.
8. Trình điều khiển thiết bị phức tạp SWC: SWC này được sử dụng để phát triển trình điều khiển thiết bị phức hợp (CDD) cho các thiết bị bên ngoài mà AUTOSAR không hỗ trợ hoặc có một số hoạt động quan trọng.
9. Nvblock SWC: SWC này được sử dụng khi tương tác với NVRAM hoặc bộ nhớ.
+ Runnable Entity:
Thực thể có thể chạy được là một phần của SWC nơi logic hành vi của ứng dụng được viết. Runnable tương tự như các chức năng trong C. Trong AUTOSAR, chúng tôi tạo Runnable trong SWC trong khi định cấu hình và khung chức năng hoặc runnable đóđược tạo trong các tệp nguồn tương ứng của SWC. Tên của chức năng khung giống như tên mà chúng tôi đặt cho Runnable tại thời điểm cấu hình. Chúng ta cần viết mã của mình trong chức năng này/Runnable, sau đó sẽ được AUTOSAR OS thực thi, mã này là ứng dụng mà SWC sẽ thực hiện. Runnables cũng có các biến và một số Runnables cũng có các điểm kích hoạt “gọi” hoặc kích hoạt runnable của chúng ta khi một điều kiện cụ thể được đáp ứng. Các điều kiện như vậy có thể được xác định trong quá trình cấu hình, các điều kiện có thể là: Init Runnable sẽ được gọi khi khởi tạo, lệnh gọi định kỳ của runnable có thể được sử dụng để gửi một số dữ liệu định kỳ, kích hoạt dựa trên các sự kiện RTE khác nhau, v.v. Dưới đây là ví dụ về khung có thể chạy được được tạo sau khi cấu hình, có thể chạy được này là của Chỉ báo SWC có tênChạy được1. Các khung có thể chạy được như vậy được tạo ra trong các tệp .c SWC .
Hình trên cho thấy cách Runnables được gói gọn trong SWC và cách các SWC khác được gói gọn trong Composition . Bằng cách nhìn vào con số này, chúng ta có thể hiểu rằng AUTOSAR tóm tắt và nhóm các thứ để tiêu chuẩn hóa tốt như thế nào. Như chúng ta biết rằng đối với mọi chức năng trong ECU, SWC có thể được dành riêng, nhưng hoạt động hoặc triển khai chức năng của nó được thực hiện bằng Runnable. Nói chung có ba loại runnables:
1. Init Runnable: Runnable này được gọi trên init của ECU
2. Định kỳ Runnable: Runnable này được sử dụng khi chúng ta cần kích hoạt định kỳ runnable này để thực hiện một số hoạt động định kỳ.
3. Server Runnable: Runnable này được sử dụng để triển khai máy chủ của giao diện cổng Client/Server .
Runnables có thể được cấu hình để kích hoạt trong các sự kiện RTE như:
1. Timing Event: Như đã giải thích ở trên, bất cứ khi nào đạt đến thời gian đã đặt, sự kiện này sẽ kích hoạt/gọi chuyên dụng có thể chạy được và nó sẽ thực hiện logic được viết trong đó. Điều này có liên quan đến ngắt hẹn giờ mà chúng tôi sử dụng trong lập trình hệ thống nhúng nói chung, trong đó ISR được gọi trên mỗi lần tràn hẹn giờ.
2. Data received event: Như tên cho thấy, sự kiện như vậy sẽ kích hoạt một sự kiện có thể chạy được bất cứ khi nào các port nhận được dữ liệu .
3. Operation Invoked Event: Sự kiện này được gọi bởi máy khách khi gọi một máy chủ có thể chạy được bằng giao diện cổng Máy khách/máy chủ.
4. Mode Switch Event: Bất cứ khi nào chế độ ECU được thay đổi, có thể kích hoạt runnable để thực hiện một số công việc. Ví dụ: chế độ tắt ECU, nếu ECU cần thực hiện một số công việc trước khi tắt, thì sự kiện đó sẽ được nối với cái có thể chạy được sẽ thực hiện công việc trước khi tắt.
5. Data Received Error Event: Một lần nữa, đây là điều dễ hiểu, bất cứ khi nào có bất kỳ lỗi nào xảy ra trong quá trình nhận dữ liệu, một runnable có thể được gọi để thực hiện hành động đối với sự kiện đó.
6. Data Send Completed Event: Sự kiện này sẽ kích hoạt một runnable nếu dữ liệu được gửi thành công để thực hiện thêm hành động khi hoàn thành truyền dữ liệu.
+ MemMap File:
MemMap là tệp tiêu đề (MemMap.h) được sử dụng để ánh xạ các hàm hoặc biến tới các vị trí bộ nhớ cụ thể trong bộ nhớ Flash hoặc RAM để tránh lãng phí RAM và sắp xếp các biến hoặc khối chức năng theo ý muốn.
Lãng Phí Bộ Nhớ Và Cách Giải Quyết
Trong lập trình hệ thống nhúng nói chung, khi chúng ta không sử dụng bất kỳ cách nào để đặt các biến hoặc hàm vào các địa chỉ bộ nhớ mong muốn, thì trình biên dịch sẽ sử dụng logic mặc định để đặt các biến vào RAM. Nhưng logic mặc định như vậy có thể tạo ra các khoảng trống không cần thiết trong bộ nhớ khi các biến có kích thước khác nhau được đặt gần đó, gây lãng phí bộ nhớ RAM. Vì vậy, các nhà phát triển có kinh nghiệm sử dụng chỉ thị #pragma để đặt các biến hoặc khối mã của họ vào vị trí mong muốn trong bộ nhớ, giúp giảm lãng phí bộ nhớ cũng như tổ chức mã và biến. Dưới đây là đoạn mã nhỏ để chỉ ra các cách lưu trữ biến thông thường tới địa chỉ bộ nhớ cụ thể.
Phương pháp đặt các biến hoặc khối chức năng ở trên vào địa chỉ mong muốn là phương pháp phổ biến nhất nhưng không thể sử dụng phương pháp này trong AUTOSAR. Bởi vì AUTOSAR nhằm mục đích chuẩn hóa mã và do đó, những “sửa đổi” như vậy không được phép trong đó. Vì vậy, để duy trì tiêu chuẩn và cách triển khai phương pháp trên, AUTOSAR sử dụng Tệp MemMap . Nó có các macro tạo điều kiện thuận lợi cho việc đặt các biến hoặc khối mã ở những nơi mong muốn. Tệp này cũng sử dụng chỉ thị #pragma kèm theo macro #define . Dưới đây là ví dụ về tệp tiêu đề MemMap:
Đoạn mã trên kích hoạt phần được sử dụng cho một số biến 8 bit và được sử dụng cho mô-đun CAN. AUTOSAR triển khai và thực thi cách đặt tên tiêu chuẩn cho macro trong tệp MemMap. Bảng bên dưới hiển thị cú pháp cần tuân theo khi chỉnh sửa hoặc thêm macro vào tệp MemMap.
Bảng trên hiển thị cú pháp tệp MemMap, tất cả các cú pháp bắt đầu và kết thúc bằng “ [ ] ” là những phần giữ chỗ mà chúng tôi nên điền thông tin từ phía chúng tôi. Ví dụ: [MSN] cho biết tên mô-đun mà biến sẽ được sử dụng, như trong ví dụ về tệp MemMap ở trên, chúng tôi đã sử dụng mô-đun “CAN” và [SIZE ] cho biết kích thước của biến, một lần nữa có tên tiêu chuẩn cho kích thước biến tương ứng:
Biến 8 bit -> 8BIT
Biến 16 bit -> 16BIT
Biến 32 bit -> 32BIT
biến có kích thước không xác định -> KHÔNG XÁC ĐỊNH
Làm Cách Nào Để Sử Dụng Tệp MemMap?
Có cơ chế sử dụng tệp MemMap trong AUTOSAR. Dưới đây là ví dụ về việc sử dụng Tệp MemMap:
Đoạn mã trên mô tả cách sử dụng cơ bản của tệp MemMap. Lời giải thích cho nó là:
+ Bất cứ khi nào chiến lược đặt biến/mã được sử dụng, chúng tôi xác định macro có tên giống với tên của macro trong tệp MemMap (trong trường hợp này là CAN_START_SEC_VAR_8BIT) phù hợp với khối biến/mã (trong trường hợp này kích thước là tiêu chí), sau đó Phải bao gồm tệp MemMap.h để gọi lệnh #pragma từ tệp MemMap và kích hoạt lưu trữ biến theo macro được xác định trong tệp MemMap và mọi thứ sau đó sẽ được lưu trữ vào các địa chỉ liên tiếp từ địa chỉ đã cho trong tệp MemMap.
+ Để tránh lưu trữ những thứ khác với biến của chúng tôi vào các địa chỉ liên tiếp sau khi kích hoạt, chúng tôi sử dụng một macro khác để hủy kích hoạt chiến lược đặt này bằng cách sử dụng cùng một macro như trong tệp MemMap để dừng chiến lược (trong trường hợp này là CAN_STOP_SEC_VAR_8BIT) và chiến lược mặc định được sử dụng để lưu trữ các biến cho đến khi bộ tiền xử lý không gặp phải macro khác. Ưu điểm của điều này là mọi thứ được thực hiện trong giai đoạn tiền xử lý và do đó các lỗi cũng được thông báo trước khi biên dịch.
+ Implementation Data Type:
Đây lại là một thuật ngữ phổ biến mà bất kỳ kỹ sư AUTOSAR nào cũng có thể gặp phải. Điều này tương tự với typedef của C bằng cách sử dụng mà chúng ta có thể tạo một loại dữ liệu cụ thể để giả sử tín hiệu của PDU . Giả sử chúng ta muốn truyền tín hiệu có tên là Alive và phạm vi của tín hiệu dự kiến sẽ nằm trong khoảng từ 0 đến 255, vì vậy chúng ta sẽ tạo kiểu dữ liệu Triển khai trong phần mềm Cấu hình như DaVinci Developer từ Vector. Triển khai Loại dữ liệu được sử dụng bởi các giao diện Cổng mà các cổng tuân theo trong khi giao tiếp với các thực thể khác. Cấu trúc của dữ liệu cũng như dung sai và giới hạn của dữ liệu đều được biết tại thời điểm cấu hình.
+ Ports And Port Interfaces:
Trong AUTOSAR, mọi giao tiếp giữa SWC và các lớp thấp hơn được thực hiện bằng cách sử dụng các cổng. Cổng là một kênh hoặc kết nối dùng để truyền dữ liệu giữa các SWC hoặc mô-đun BSW . Vì AUTOSAR nhằm mục đích tiêu chuẩn hóa nên dữ liệu sẽ được truyền giữa các thực thể cần phải được biết tại thời điểm cấu hình, do đó, các Cổng cũng không ngoại lệ.
Các cổng thuộc về chính xác một SWC tại một thời điểm. Cổng có thể hoặc không thể được kết nối với đầu kia. Có hai loại cổng:
+ Cổng bắt buộc: Loại cổng này được sử dụng khi dữ liệu được nhận hoặc yêu cầu hoặc được mong đợi từ các thực thể khác.
+ Cổng của nhà cung cấp: Loại cổng này được sử dụng khi dữ liệu được truyền đi hoặc SWC là nhà cung cấp một số dịch vụ cho các thực thể khác.
Giao diện cổng là giao diện xác định loại thông tin được truyền hoặc nhận giữa hai cổng. Giao diện cổng giống như các bản in màu xanh của các cổng xác định một “giao thức” được tuân theo bởi cổng của SWC. Giao diện cổng có thể tái sử dụng tức là chúng có thể được sử dụng bởi nhiều cổng. Cấu hình giao diện cổng được thực hiện tại thời điểm cấu hình hệ thống và các cổng sẽ tuân theo giao diện sẽ được gán cho các cổng đó.
AUTOSAR phân biệt giữa ba loại giao diện Cổng:
1. Giao diện AUTOSAR: Đây là giao diện chung mà chúng tôi sẽ tạo cho các cổng của SWC. Nó được sử dụng để tương tác với các SWC khác hoặc Lớp trừu tượng SWC và ECU.
2. Giao diện AUTOSAR được chuẩn hóa: Giao diện AUTOSAR được chuẩn hóa được AUTOSAR xác định trước, giao diện này được ứng dụng SWC sử dụng khi tương tác với các dịch vụ BSW như Trình quản lý ECU, v.v.
3. Standardized Interface: Đây cũng là một loại interface được định nghĩa sẵn theo chuẩn AUTOSAR là C API . Nó được sử dụng giữa các mô-đun BSW, giữa RTE và OS, v.v.
Nhìn chung có 2 loại Giao diện cổng:
1. SenderReceiverInterface: Đây là loại giao diện đơn giản nhất mà chúng ta có thể tạo. Loại giao diện này được sử dụng khi dữ liệu được truyền giữa các thực thể là loại không đồng bộ. Không đồng bộ ở đây có nghĩa là dữ liệu sẽ được nhận bởi các cổng Yêu cầu bất kỳ lúc nào sau khi bắt đầu yêu cầu.
2. ClientServerInterface: Loại giao diện này được sử dụng khi dữ liệu được nhận thuộc loại đồng bộ. Ở đây có nghĩa là đồng bộ, máy khách sẽ yêu cầu dữ liệu từ máy chủ sẽ cung cấp. Máy chủ thực hiện hoạt động của nó và cung cấp thông tin cần thiết cho máy khách. Trong trường hợp này, máy chủ chỉ “hoạt động” khi máy khách “kích hoạt” nó. Trong trường hợp này, khách hàng đợi cho đến khi thao tác hoàn tất. Nói một cách đơn giản, ClientServerInterface có một thao tác được thực thi và gọi lại sau khi hoàn thành trong khi SenderReceiverInterface có trao đổi dữ liệu
+ Hardware Objects:
Thuật ngữ Đối tượng phần cứng được sử dụng liên quan đến bus CAN. Đối tượng phần cứng là một khoảng trống trong RAM bộ điều khiển CAN nơi đặt PDU . Khi PDU nằm trong RAM của bộ điều khiển CAN, nó được gọi là Đối tượng phần cứng.
+ Hardware Object Handle:
Xử lý đối tượng phần cứng (HOH) đại diện cho một tham chiếu trừu tượng của hộp thư CAN có tất cả các tham số khung CAN như DLC, CANID và dữ liệu. Các lớp trên không thể trực tiếp “tạo” khung CAN bằng dữ liệu và điều đó sẽ 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 sẽ đảm bảo tính độc lập của phần cứng bằng cách trừu tượng hóa .
Có hai loại xử lý đối tượng Phần cứng:
1. Hardware Transmit Handle (HTH): HOH này được sử dụng trong quá trình truyền khung CAN.
2. Hardware Receive Handle (HRH): HOH này được sử dụng trong quá trình nhận khung CAN.
HOH được CanIf sử dụng và được tham chiếu trong đó dựa trên bố cục bộ đệm phần cứng CAN. HOH được sử dụng làm đối số trong khi gọi các dịch vụ giao diện trình điều khiển CAN lớp dưới.
Các handle này là các cấu trúc trừu tượng dùng để tham chiếu đến một cấu trúc đối tượng phần cứng CAN, chứa các thông số liên quan đến CAN như CanId, DLC và data.
Hình trên cho thấy cách các tham chiếu được đan xen trong các mô-đun như CanIf, CAN Driver và CAN Controller. Các đường mũi tên hiển thị trong hình là tham chiếu chứ không phải kết nối . Bây giờ tôi đoán đã rõ ràng hộp thư CAN là gì và Đối tượng phần cứng là gì và các tham chiếu ở đó như thế nào.
+ Container Concept In AUTOSAR:
AUTOSAR nhằm mục đích chuẩn hóa quy trình phát triển phần mềm của ECU, do đó nó thực hiện các tài liệu và bước khác nhau . Chuẩn bị các tài liệu đó theo cách thủ công và duy trì chúng theo tiêu chuẩn AUTOSAR là một công việc tẻ nhạt. Vì vậy, để giải quyết vấn đề này, phần mềm được sử dụng để chúng tôi có thể định cấu hình các khối AUTOSAR cũng như tạo tài liệu và mã. Trong cấu hình, các thùng chứa được sử dụng trong GUI chứa cài đặt/thông tin của một khối BSW cụ thể. Ví dụ: Com có danh sách các PDU và tín hiệu để mỗi PDU có một vùng chứa bên dưới mô-đun Com. Vì vậy, vùng chứa không là gì ngoài nơi chúng tôi định cấu hình hoặc lưu trữ thông tin liên quan đến khối AUTOSAR trong trình cấu hình.
+ CAPL Script:
Tập lệnh CAPL hoặc C AN Ngôn ngữ lập trình P truy cập là một ngôn ngữ giống như tập lệnh C được sử dụng để giao tiếp với các đối tượng của bảng điều khiển trong CANOe . Ví dụ: một bảng điều khiển có mạng LED và LIN, sau đó bạn có thể viết tập lệnh CAPL để mô phỏng (cũng như giao diện với các thiết bị trong thế giới thực) các điều kiện như điều gì sẽ xảy ra khi nhận tín hiệu LIN cho dù đèn LED trên bảng điều khiển có sáng hay không.
+ Multiplicity:
Multiplicity có liên quan đến khái niệm vùng chứa đã giải thích ở trên. Nó cho biết số lượng vùng chứa phụ/tham số có thể được thêm vào bên dưới một vùng chứa cụ thể. Nó cũng cho biết vùng chứa phụ hoặc tham số nên là tùy chọn hay bắt buộc.
Các giá trị bội số có hai loại:
+ Upper Multiplicity: Giá trị bội số trên cho biết số lượng bộ chứa phụ cao nhất có thể được thêm vào.
+ Lower Multiplicity: Giá trị bội số thấp hơn cho biết số lượng vùng chứa phụ thấp nhất có thể được thêm vào trong một vùng chứa.
Chúng ta có thể hiểu liệu một vùng chứa con hoặc tham số nên là tùy chọn hay duy nhất bằng cách diễn giải các giá trị bội số trên và bội số dưới. Dưới đây là một số ví dụ về sự kết hợp bội số và ý nghĩa của chúng:
Từ bảng chúng ta có thể hiểu những điều sau đây:
+ Khi cả hai bội số bằng nhau, số của chúng biểu thị các vùng chứa phụ bắt buộc.
+ Và bất cứ khi nào cả hai bội số không bằng nhau, thì số lượng vùng chứa thấp nhất có thể được thêm vào phải khớp với bội số thấp hơn và số lượng vùng chứa cao nhất phải khớp với bội số cao hơn và điều đó cũng có nghĩa là cấu hình của vùng chứa này là tùy chọn.
+ Và bội số trên với *(dấu hoa thị) cho biết chúng ta có thể có các vùng chứa/vùng chứa phụ vô hạn. Ví dụ về điều này có thể là trong mô-đun Com, chúng ta có thể có n số PDU .
Bạn sẽ bắt gặp thuật ngữ multiplicity trong quá trình cấu hình BSW . Số multiplicity không được tạo trực tiếp trong mã thay vì cấu hình ảnh hưởng đến multiplicity được tạo trong code.
+ Assembly Connector:
Assembly Connector được sử dụng khi giao tiếp cần được thực hiện giữa các SWC trong SWC Thành phần. Các đầu nối này kết nối các cổng của SWC cần được kết nối. Các đầu nối này là bước tiếp theo của cấu hình cổng, tất cả các cổng của SWC cần kết nối đều được kết nối bằng đầu nối lắp ráp. Bạn sẽ sử dụng điều này trong khi Cấu hình Hệ thống .
+ Delegation Connector:
Trình Delegation Connector được sử dụng khi một số cổng của SWC cần được tiếp xúc với thế giới bên ngoài của Composition SWC , khả năng tiếp xúc này có thể được kết nối với các SWC khác bằng cách sử dụng trình kết nối Assembly hoặc kết nối với BSW. Điều này là do, AUTOSAR không cho phép các SWC giao tiếp trực tiếp với bên ngoài Thành phần, do đó, để giao tiếp bên ngoài Thành phần và ủy quyền dữ liệu của các SWC bên trong với thế giới bên ngoài, các trình kết nối ủy quyền được sử dụng. Một lần nữa, bạn sẽ sử dụng thuật ngữ này trong Cấu hình Hệ thống.
Tôi hy vọng tôi đã giải thích các điều trên bằng cách đưa ra lời giải thích đơn giản. Danh sách các thuật ngữ đưa ra ở đây không đầy đủ sẽ được bổ sung thêm và trang này sẽ được cập nhật thường xuyên nhé.
Xem thêm :
Autosar là gì ? Tổng quan chi tiết về Autosar cho người mới
AUTOSAR RTE Runtime Environment – Môi trường Thực thi AUTOSAR
Phương pháp phát triển AUTOSAR
