Autosar là gì ? Tổng quan chi tiết về Autosar cho người mới

Bởi

12 Tháng 11, 2024

Autosar là gì ?

Điều kiện học Autosar ban đầu

Người đọc phần này và sử dụng AUTOSAR cần phải hiểu biết về Hệ thống nhúng, lập trình C, kiến trúc phân lớp cũng như các giao thức truyền thông như CAN, I2C, v.v. Bởi vì AUTOSAR là một bước tiến cao hơn của Hệ thống nhúng, nên việc nắm rõ những thuật ngữ trên là điều thiết yếu.

AUTOSAR là viết tắt của Kiến trúc Hệ thống Mở Ô tô (AUTomotive Open System AR chitecture), được tổ chức thành một kiến trúc nhiều lớp với các thông số kỹ thuật tiêu chuẩn mà một liên minh gồm những công ty như BMW Group, BOSCH, Continental, Daimler, Ford, General Motors, PSA Group, Toyota và VOLKSWAGEN đã thiết lập. Đây là các thành viên chính tạo nên quan hệ đối tác AUTOSAR, đóng vai trò quan trọng trong việc thành lập AUTOSAR. Có nhiều loại tư cách thành viên mà một thực thể có thể tham gia vào quá trình phát triển AUTOSAR, bao gồm Thành viên cốt lõi, Thành viên cao cấp và Thành viên phát triển. Tôi đã đề cập đến các thành viên cốt lõi ở trên, nhưng cũng có nhiều thành viên cao cấp tham gia vào việc phát triển công cụ, cung cấp dịch vụ, v.v. Mục tiêu của AUTOSAR là chuẩn hóa quy trình phát triển phần mềm cho ECU dùng trong các ứng dụng ô tô.
AUTOSAR đã thiết lập một kiến trúc phân lớp tương tự như mô hình OSI. Nó bao gồm nhiều lớp khác nhau nhằm xử lý và trừu tượng hóa các hoạt động của mã nguồn. AUTOSAR được áp dụng cho các bộ điều khiển vi mô, chủ yếu phục vụ cho các ứng dụng trong lĩnh vực ô tô sử dụng các giao thức như CAN, Flex Ray, Ethernet, v.v. Được thiết kế cho các ứng dụng dựa trên vi điều khiển, nó được phát triển với mục tiêu tiết kiệm bộ nhớ do những hạn chế về tài nguyên của vi điều khiển.

Hình minh họa là một cấu trúc AUTOSAR phân lớp được đơn giản hóa. Thuật ngữ “đơn giản hóa” được sử dụng vì trong mỗi khối vẫn có các lớp phức tạp hơn. Dưới đây là mô tả ngắn gọn về các lớp:

Application Layer

Lớp này chứa mã ứng dụng ở vị trí cao nhất. Nó có thể bao gồm nhiều khối ứng dụng khác nhau, gọi là Software Components (SWC), cho từng chức năng mà ECU cần hỗ trợ dựa trên ứng dụng cụ thể. Ví dụ, các chức năng như cửa sổ điện và đo nhiệt độ sẽ sở hữu các SWC riêng lẻ. Điều này không phải là tiêu chuẩn cố định, mà phụ thuộc vào thiết kế của nhà phát triển.

AUTOSAR RTE

Xem thêm tại : AUTOSAR RTE Runtime Environment – Môi trường Thực thi AUTOSAR

Đây là một trong những lớp cơ bản và quan trọng của AUTOSAR, cung cấp khả năng giao tiếp giữa các SWC và cả các ECU khác nhau. Lớp Application Layer sử dụng lớp này để giao tiếp với các lớp bên dưới thông qua các cổng. Để tìm hiểu thêm về RTE, bạn có thể tham khảo liên kết này.

Services Layer

Lớp này đề xuất nhiều dịch vụ khác nhau cho ứng dụng sử dụng. Một số dịch vụ điển hình bao gồm: System Services, Memory Services, Crypto Services, Off board communication services, và Communication services.

ECU Abstraction Layer

Lớp này cung cấp các tóm tắt liên quan đến ECU. Nó bao gồm các lớp trừu tượng khác nhau như lớp I/O Hardware Abstraction layer, On board device abstraction, Memory hardware Abstraction, Crypto hardware abstraction, v.v., nhằm mục đích làm cho phần cứng của ứng dụng trở nên độc lập.

Lý do phải có Autosar

Dưới đây là một số khó khăn thường gặp khi phát triển phần mềm cho ECU:

– Ngành hệ thống nhúng rất phong phú với nhiều nhà sản xuất chất bán dẫn, phần cứng và phần mềm khác nhau có thể lựa chọn tùy thuộc vào nhu cầu của ứng dụng. Sự đa dạng này khiến cho việc phát triển trở nên phức tạp và khả năng di động của mã trở nên khó khăn, từ đó gia tăng chi phí phát triển.
– Ô tô là một cấu trúc phức tạp với nhiều hệ thống nhúng nhỏ gọi là Bộ điều khiển điện tử (ECU), vì vậy việc bảo trì và phát triển mã cho các bộ điều khiển này không hề đơn giản. Độ phức tạp còn tăng lên nếu các ECU sử dụng các MCU khác nhau để đáp ứng yêu cầu về chi phí, dẫn đến việc mỗi ECU sẽ có phần mềm riêng biệt do sự khác nhau trong nền tảng phần cứng.
– Để tạo ra sự đồng nhất, đôi khi cần phát triển và tuân theo những tiêu chuẩn được tùy chỉnh (tiêu chuẩn tùy chỉnh có nghĩa là phát triển một giao thức liên lạc mà tất cả các ECU trong mạng đồng tình sử dụng) để giao tiếp với các ECU khác. Cách viết phần mềm truyền thống tồn tại những khó khăn trong việc bảo trì và khả năng chuyển giao hoặc tái sử dụng mã rất hạn chế.
– Một chiếc xe hơi có nhiều bộ phận được sản xuất bởi các công ty khác nhau được gọi là nhà cung cấp cấp 1, cung cấp linh kiện cho các OEM như BMW, Volkswagen, và những hãng tương tự. Hiện nay, nhiều bộ phận cơ khí đã thông minh hơn nhờ tích hợp ECU để cải thiện khả năng kiểm soát và hiệu suất. Bởi vậy, các ECU này cũng cần một chuẩn giao tiếp chung để kết nối với ECU của OEM, dẫn đến việc cần triển khai và duy trì một tiêu chuẩn tùy chỉnh.

Vì vậy, cần có một hệ thống hạ tầng phần mềm đồng nhất để giải quyết những vấn đề này, và AUTOSAR đã thực hiện rất tốt trong việc này.
AUTOSAR áp dụng kiến trúc nhiều lớp với các tầng chuyên biệt khác nhau để thực hiện các chức năng và trừu tượng hóa. Code ứng dụng hoàn toàn có khả năng di động bởi vì AUTOSAR được thiết kế sao cho code ứng dụng có thể hoạt động độc lập với phần cứng, cho phép cùng một đoạn mã chạy trên các nền tảng phần cứng khác nhau. Trong AUTOSAR, có một tầng chuyên biệt hỗ trợ cho các chức năng phần cứng, gọi là MCAL (Trừu tượng hóa bộ điều khiển vi mô), cung cấp trình điều khiển để truy cập vào các thiết bị ngoại vi cơ bản của MCU. Nhờ vào tính năng giao tiếp chuẩn mà AUTOSAR cung cấp, các ECU có thể trao đổi thông tin với nhau mà không cần quan tâm đến nhà phát triển ECU (dù là OEM hay Cấp 1) và do đó không cần duy trì tiêu chuẩn giao tiếp tùy chỉnh. Các ECU áp dụng AUTOSAR có khả năng giao tiếp qua lại mặc dù có sự khác biệt về phần cứng cơ bản. Hầu hết các nhà sản xuất chip đều cung cấp lớp MCAL của AUTOSAR, nhưng nếu không có thì các nhà phát triển sẽ phải tự viết hoặc thuê các công ty bên ngoài để làm lớp MCAL này.

Đây không phải là một hạn chế vì AUTOSAR đã cung cấp tất cả các trình điều khiển và lớp cần thiết rồi sao?

Thực tế, đây không phải là một trở ngại vì trong bối cảnh hiện nay có nhiều yêu cầu thời gian căng thẳng để hoàn thành dự án. Tuy nhiên, khi xem xét các vấn đề đã nêu trong thiết kế phần mềm truyền thống, việc phát triển phần mềm nhanh chóng để đáp ứng nhu cầu là rất khó khăn, do đó AUTOSAR trở nên hữu ích. Dù AUTOSAR có vẻ đã bao gồm mọi thứ, nhưng chúng ta vẫn cần viết mã theo cách thủ công cho chức năng của SWC trong Runnable của SWC.

Nếu tôi sử dụng thiết bị ngoại vi bên ngoài mà AUTOSAR không hỗ trợ thì có vấn đề gì không?

Nếu bạn đang làm việc với thiết bị không được AUTOSAR hỗ trợ, bạn có thể sử dụng Complex Device Drivers SWC để tương tác với thiết bị đó. Lớp này cho phép bạn kết nối trực tiếp đến lớp MCAL từ ứng dụng và giao tiếp với ECU, nhưng bạn sẽ cần tự phát triển phần mềm cho nó và vì phụ thuộc vào phần cứng, nên nó không thể tái sử dụng hoặc được di động như SWC.

Các loại AUTOSAR

Có hai loại kiến trúc AUTOSAR: Classic và Adaptive. Kiến trúc Classic cung cấp tất cả các mô-đun thông dụng cần thiết cho một ứng dụng, trong khi kiến trúc Adaptive có thể được tùy chỉnh và điều chỉnh cho ứng dụng cụ thể bằng cách loại bỏ các mô-đun không cần thiết. Phiên bản Classic hiện tại là 4.4.0 và phiên bản Adaptive hiện tại là 19.03.

Các hình ảnh liên quan.

Quy Trình Phát Triển Autosar

AUTOSAR có thể gây khó khăn cho các nhà phát triển mới, do đó phần này sẽ giới thiệu về việc bắt đầu với dự án sử dụng AUTOSAR.

Xem Phương pháp phát triển Autosar chi tiết hơn tại :

Phương pháp phát triển Autosar

AUTOSAR đã xây dựng một kiến trúc phân lớp cùng với những thông số kỹ thuật tiêu chuẩn, và phần mềm cho ECU dựa trên AUTOSAR được phát triển theo các thông số kỹ thuật này. Phần mềm có thể được phát triển bởi các lập trình viên hoặc cũng có thể tạo mã nguồn bằng cách sử dụng các phần mềm cấu hình ECU khác nhau như Vector’s DaVinci Configurator and Developer, K-SAR, v.v. Phần mềm này chủ yếu dành cho những nhà phát triển có kinh nghiệm, cho phép bạn tạo mã nguồn thông qua việc định cấu hình các yêu cầu ứng dụng trong phần mềm giao diện đồ họa, sau đó tích hợp mã ứng dụng vào mã đã tạo ra trước đó. Bài viết này sẽ giúp bạn tìm hiểu về quy trình cấu hình ECU dựa trên AUTOSAR.

Cần lưu ý rằng bài viết này sẽ không đi vào chi tiết từng bước, mà chỉ cung cấp cái nhìn tổng quan về quy trình, điều này sẽ hữu ích cho những người mới bắt đầu.

Tất cả các ECU và toàn bộ hệ thống mạng trong xe được gọi là Hệ thống, và trước tiên Hệ thống sẽ được định cấu hình, sau đó từng ECU trong hệ thống này sẽ được cấu hình.

Quy trình tạo mã ECU từ Cấu hình hệ thống đến ECU thực thi

Hình ảnh trên minh họa quy trình tạo mã ECU từ Cấu hình hệ thống đến ECU thực hiện. Mặc dù hình vẽ chỉ ra tệp thực thi dưới dạng .exe, nhưng điều này không nên bị nhầm lẫn với tệp .exe trên PC Windows 😀. Tại đây, .exe ám chỉ đến một tệp thực thi tổng quát có thể là .elf, .bin, và các định dạng khác. AUTOSAR sử dụng một định dạng tệp riêng để trao đổi thông tin giữa các bước trong quy trình. Định dạng này tương tự như XML, nhưng trong bối cảnh của AUTOSAR, nó được gọi là tệp .arxml (Ngôn ngữ đánh dấu mở rộng AUTOSAR). Phần mềm cấu hình sẽ đọc và xử lý tệp này để tạo ra mã dựa trên thông tin có trong nó.

Một số bước trong quá trình cấu hình bao gồm

Cấu hình Hệ thống: Trong bước này, các ECU cần thiết cho xe hơi (Hệ thống) cùng với phần cứng của chúng được thiết lập, đồng thời các SWC và Composition SWC được gán đến các ECU thích hợp.
Tạo mô tả cấu hình hệ thống: Sau khi hoàn tất cấu hình ở bước một, kết quả sẽ được ghi lại trong tệp Mô tả Cấu hình Hệ thống với định dạng .arxml.
Tạo tệp trích xuất ECU: Sử dụng tệp arxml mô tả cấu hình hệ thống từ bước hai làm đầu vào, một tệp mới mang tên tệp arxml trích xuất ECU sẽ được tạo ra. Tệp này chứa thông tin chỉ về các ECU riêng lẻ, không giống như tệp mô tả Cấu hình Hệ thống, vốn lưu giữ thông tin cho tất cả các ECU trong xe.
Cấu hình ECU: Ở giai đoạn này, ECU được trích xuất sẽ được sử dụng làm đầu vào và ECU tương ứng sẽ được thiết lập theo yêu cầu của ứng dụng. Các thiết lập bao gồm cấu hình BSW, cấu hình hệ điều hành, v.v.

Tạo Mô tả Cấu hình ECU: Giai đoạn này sẽ tạo ra đầu ra cho bước 4, tức là tạo tệp arxml để mô tả cấu hình ECU, tệp này sẽ được sử dụng tiếp để tạo ra các cấu hình có thể thực thi.
Bạn nên lưu ý rằng các tệp có hậu tố “Description” là kết quả đầu ra từ bước hoặc quy trình tương ứng. Ví dụ, Mô tả Cấu hình Hệ thống arxml là kết quả của bước Cấu hình Hệ thống.

Mô tả Nội dung của Tệp Thông tin Mô tả Cấu hình Hệ thống Là Gì?

Tệp Mô tả Cấu hình Hệ thống (được tạo ra sau khi thực hiện Cấu hình Hệ thống) chứa tất cả thông tin cấu hình của hệ thống như:

Các ECU có trong hệ thống.
Các hệ thống truyền thông kết nối giữa các ECU và cấu hình của chúng.
Ma trận truyền thông chỉ ra dữ liệu sẽ gửi và nhận cho các hệ thống truyền thông đó. Vì mục tiêu của AUTOSAR là tiêu chuẩn hóa toàn bộ quá trình phát triển, mọi dữ liệu, kích thước, v.v., cần phải được định cấu hình tại thời điểm cấu hình.
Định nghĩa SWC với các cổng và giao diện cũng như cách kết nối của chúng.
Mapping của các SWCs (Các thành phần Phần mềm) tới các ECU.
=> Tệp này đóng vai trò là đầu vào cho việc cấu hình ECU. Tệp trích xuất ECU tương tự như Mô tả Cấu hình Hệ thống nhưng chỉ chứa thông tin liên quan đến ECU cụ thể.

File mô tả cấu hình ECU chứa gì?

File extract ECU chỉ định các yếu tố cấu hình, nhưng điều này không đủ để phát sinh mã có thể hoạt động trên phần cứng. Bởi vì file này thiếu thông tin cấu hình cấp thấp cần thiết để thiết lập các lớp dưới của kiến trúc AUTOSAR. Do đó, file mô tả cấu hình ECU cung cấp thông tin mà phần mềm sử dụng để cấu hình và tạo ra các tệp .c và .h sẽ được biên dịch và chạy trên phần cứng

Xem thêm :

Các vấn đề chính trong hệ thống nhúng trên xe: Nền tảng phần mềm chuẩn AUTOSAR

Giới thiệu về nền tảng phần mềm chuẩn ô tô, AUTOSAR

AUTOSAR RTE Runtime Environment – Môi trường Thực thi AUTOSAR

Bởi

eiovn

12 Tháng 11, 2024

AUTOSAR RTE Runtime Environment

Kiến trúc AUTOSAR được phân chia thành ba phần chính

Tầng ứng dụng

Bao gồm các phần mềm ứng dụng cụ thể được phát triển nhằm thực hiện một số chức năng hoặc nhiệm vụ nhất định.
Môi trường Thực thi AUTOSAR (RTE) – RTE đóng vai trò như một lớp trung gian kết nối tầng ứng dụng với tầng phần mềm cơ bản (BSW). RTE đảm nhận việc truyền thông giữa các phần mềm trong tầng ứng dụng (cả giao tiếp nội bộ và giữa các ECU) cũng như giữa tầng ứng dụng và BSW.

Phần mềm Cơ bản (BSW)

Module phần mềm cơ bản (BSW) là một phần mềm đã được chuẩn hóa và cung cấp các dịch vụ đa dạng hỗ trợ cho hoạt động của tầng phần mềm phía trên.
Các module của tầng ứng dụng tương tác với nhau thông qua Bus Chức năng Ảo (VFB). Nói chung, VFB có thể được hiểu là khái niệm về mô hình hệ thống và cách thức truyền thông. Đây là một thực thể logic xác định phương tiện giao tiếp giữa các module ứng dụng trong kiến trúc AUTOSAR.

Môi trường Thực thi AUTOSAR (RTE)

Là phần kết nối quan trọng trong cấu trúc ECU của AUTOSAR. Nó thực thi các giao diện được VFB cung cấp (thực tế nó đảm bảo việc phân bổ bộ nhớ, xác định cổng, v.v.) để tạo điều kiện thuận lợi cho sự tương tác giữa các thành phần phần mềm.
Để dễ hiểu, VFB được triển khai ở cấp ECU nhờ vào RTE. Chúng ta sẽ khám phá vai trò của RTE trong kiến trúc AUTOSAR thông qua một ví dụ về quản lý cửa bên. Tình huống đề xuất là: “nếu cửa bên mở thì cần thông báo cho tài xế rằng cửa bên đang mở.”

Chúng ta có thể giải quyết vấn đề này bằng cách tạo ra hai thành phần phần mềm trên hai ECU khác nhau. Thành phần phần mềm ‘A’ trong ECU 1 sẽ lấy tín hiệu từ cảm biến cửa qua PORT A. Dựa trên tín hiệu thu được từ cảm biến, nó sẽ xác định trạng thái cửa và gửi thông tin này đến thành phần phần mềm ‘B’ qua PORT B. Thành phần phần mềm ‘B’ ở ECU 2 sẽ nhận tín hiệu qua PORT A. Tiếp đó, thành phần phần mềm ‘B’ sẽ Bật (ghi) đèn LED để cảnh báo tài xế nếu cần thông qua PORT B

Giao diện Virtual Function Bus (VFB)

Thiết kế hệ thống cấp cao này được tạo ra bằng cách sử dụng Virtual Function Bus (VFB), và một file XML sẽ được tạo ra bởi một công cụ của nhà sản xuất (OEM). File XML này sẽ chứa tất cả các chi tiết cấu hình và được sử dụng như một tài liệu tham chiếu. Nhà sản xuất (OEM) sẽ chia sẻ file XML (file hệ thống) và cũng xác định phiên bản tiêu chuẩn AUTOSAR (ví dụ, AUTOSAR 4.2) mà phần mềm cần được phát triển theo. Công ty Tier 1 sẽ tải file XML này vào công cụ của họ và trích xuất tất cả thông tin ở cấp độ hệ thống. Sau đó, Tier 1 sẽ hiện thực hóa file hệ thống này vào một ECU thực tế.

Bắt đầu thảo luận về cách thiết kế RTE và trách nhiệm của nó

– Công việc chính đầu tiên của RTE là đọc dữ liệu từ chân đọc (read pin). Để làm điều này, thiết kế của RTE phải bao gồm thông tin về số byte sẽ được truyền và nhận từ chân (PIN), API nào cần được gọi, v.v.

– Phần mềm ứng dụng được phát triển bằng các **runnable**. Runnable là các hàm nhỏ. Giả sử thành phần phần mềm ứng dụng ‘A’ có ba runnable. RTE chịu trách nhiệm thực thi các runnable này theo một thứ tự cụ thể. RTE sẽ xác định thứ tự, cấp phát bộ nhớ và đảm bảo rằng các runnable được thực thi đúng trình tự.

– Hai thành phần phần mềm khác nhau có thể chia sẻ cùng bộ nhớ để tiết kiệm dung lượng bộ nhớ. Điều này cũng được quản lý bởi RTE.

– Hệ điều hành (OS) sẽ chạy độc lập. OS sẽ kích hoạt RTE khi cần thực hiện một tác vụ nào đó. RTE chịu trách nhiệm thực thi tác vụ khi nhận được yêu cầu từ OS.

– RTE cũng có trách nhiệm ước tính thời gian cần thiết để hoàn thành một tác vụ. Nó sẽ lưu trữ thời gian này trong bộ nhớ và tạo một bản sao ở một vị trí bộ nhớ khác. Khi cần, nó sẽ chia sẻ giá trị từ bộ nhớ sao chép mà không làm gián đoạn quá trình thực thi hiện tại. Việc tạo bộ nhớ có thể chia sẻ là một nhiệm vụ quan trọng của RTE.

– RTE cũng đảm bảo rằng dữ liệu được nhận theo đúng thứ tự. Thứ tự byte sẽ được giữ nguyên để đảm bảo tính đáng tin cậy của dữ liệu.

– Phần mềm ứng dụng sẽ chỉ giao tiếp với BSW thông qua RTE. Tuy nhiên, trong những trường hợp đặc biệt khi tốc độ thực thi là rất quan trọng, phần mềm ứng dụng có thể truy cập trực tiếp dữ liệu từ BSW.

Tình huống ví dụ

Khi API **READ** được gọi bởi thành phần phần mềm ứng dụng, RTE sẽ đọc giá trị của cảm biến từ chân I/O của vi điều khiển thông qua BSW. Giá trị của cảm biến sẽ được truyền lại cho phần mềm ứng dụng qua một hàm callback. Logic trong phần mềm ứng dụng A có thể được viết với hai runnable (chúng ta giả định một logic đơn giản để dễ hiểu). **Runnable đầu tiên** sẽ đọc giá trị của cảm biến từ RTE và có thể tính toán thời gian cửa mở. **Runnable thứ hai** trong thành phần phần mềm A sẽ lấy giá trị này từ runnable đầu tiên; nó cũng sẽ truy xuất giá trị cảm biến đã được hiệu chỉnh được lưu trữ trong RTE và so sánh với giá trị nhận được từ runnable đầu tiên. Nếu giá trị này vượt quá một ngưỡng nhất định (giả sử là 3 giây), runnable thứ hai sẽ gửi tín hiệu đến thành phần phần mềm B ở ECU khác để cảnh báo người lái rằng cửa xe đang mở. Tín hiệu này sẽ được gửi qua **cổng B của ECU 1**.

RTE lúc này sẽ đọc cổng B và gọi ngăn xếp giao tiếp (communication stack). Nếu dữ liệu là một tín hiệu định kỳ, ngăn xếp giao tiếp sẽ đọc dữ liệu từ bộ đệm theo chu kỳ. Nếu là dữ liệu kích hoạt theo yêu cầu, RTE sẽ thông báo cho ngăn xếp giao tiếp khi có kích hoạt. Dữ liệu trong bộ đệm sẽ tồn tại dưới dạng **Programmable Data Units (PDU)**. Ngăn xếp giao tiếp sẽ chuyển đổi thành khung CAN hoặc khung FLEXRAY tùy theo cấu hình và gửi dữ liệu đến ECU thứ hai qua giao diện/bus.

**Logic ngược lại** sẽ được áp dụng ở ECU thứ hai để giải mã dữ liệu và kích hoạt đèn LED.

Cần lưu ý rằng tất cả các thành phần đang chạy độc lập. RTE chịu trách nhiệm quản lý bộ nhớ và căn chỉnh, phân phối dữ liệu, và đồng bộ hóa thời gian thực.

Xem thêm :

Lớp RTE trong AUTOSAR (VFB, Môi trường Thời gian chạy, Giao diện Truyền thông)

Autosar Blog

Phương pháp phát triển AUTOSAR: Từ cấu hình hệ thống đến hoạt động của bộ điều khiển

Bởi

eiovn

11 Tháng 11, 2024

Phương pháp AUTOSAR

Phương pháp AUTOSAR: Là quy trình phát triển chung được định nghĩa trong AUTOSAR

1. Cấu hình hệ thống:
• Đây là giai đoạn cấu hình hệ thống, định nghĩa cấu hình các thành phần và kết nối giữa các thành phần.
• Phát triển tài liệu kỹ thuật cho các SW component (SWC Description).
2. Thực hiện thành phần:
• Tiến hành cài đặt mã cho các thành phần đã cấu hình trong giai đoạn trước là Configure System.
3. Trích xuất thông tin ECU:
• Trích xuất chỉ thông tin cần thiết để triển khai phần mềm điều khiển cụ thể từ thông tin cấu hình hệ thống.
4. Cấu hình ECU:
• Tiến hành các thiết lập liên quan đến bộ điều khiển.
• Phát triển tài liệu kỹ thuật cho cấu hình bộ điều khiển ECU (ECU Configuration Description).
5. Tạo file thực thi:
• Tạo file thực thi hoạt động trên bộ điều khiển.
• Tạo hình ảnh thực thi thông qua biên dịch và liên kết.

Quá trình thiết kế ứng dụng trong giai đoạn cấu hình hệ thống sẽ hoạt động trên bộ điều khiển ECU qua các bước dưới đây:

Application SW:

Thiết kế phần mềm ứng dụng thông qua một tập hợp các SW component được kết nối mà không tính đến bộ điều khiển. Một hệ thống được biểu diễn bằng tập hợp các thành phần. Các chức năng phụ được chia thành nhiều thành phần. Các SW component trao đổi thông tin với nhau thông qua giao diện AUTOSAR.
Quá trình thiết kế phần mềm ứng dụng là quá trình phát triển SWC Description.

VFB: Virtual Functional Bus.

Khi phát triển ứng dụng lần đầu, việc phát triển diễn ra trên VFB. VFB là viết tắt của Virtual Functional Bus, đề cập đến một bus chức năng ảo mà các SW component kết nối với nhau để giao tiếp. Đây là một bus truyền thông không tồn tại thực sự, cho phép thực hiện phần mềm ứng dụng ngay cả khi phần cứng chưa được xác định

VFB biểu diễn giao tiếp giữa các thành phần dưới dạng ký hiệu. Việc ánh xạ các thành phần đến ECU không được thực hiện ở giai đoạn này; chỉ có việc định nghĩa luồng giao tiếp giữa các thành phần từ góc độ logic. Các SW component nằm trên VFB sử dụng các giao diện AUTOSAR trừu tượng như Sender-Receiver và Client-Server. Trong trường hợp này, phần mềm ứng dụng không biết có điều gì đang xảy ra trên VFB.
VFB không chỉ định nghĩa luồng giao tiếp trong một ECU mà còn giữa các ECU. Tuy nhiên, mỗi SW component phải được thực hiện trong một ECU duy nhất. Nếu muốn phân phối chức năng của một SW component sang nhiều ECU, cần phải tách rời và triển khai chính SW component đó.

Ánh xạ ECU: Phân bổ bộ điều khiển.

Khi phần cứng và bộ điều khiển ECU đã được xác định, tất cả các SW component sẽ được chọn và định nghĩa xem chúng sẽ được ánh xạ (Mapping) vào ECU nào. Các thành phần ảo đã được kết nối trên VFB giờ đây sẽ được kết nối thực tế.
Nói cách khác, kết nối giữa các thành phần ảo trên VFB sẽ được thay thế bằng các kết nối biến trong bộ điều khiển hoặc bằng các giao thức truyền thông mạng thực tế như CAN và FlexRay.

RTE: Run-Time Environment.

Tiếp theo, cấu hình (Configuration) sẽ được thiết lập cho RTE và lớp BSW để thực thi các SW component trên từng ECU. RTE là viết tắt của Run-Time Environment, là giao diện thực tế giữa các SW component hoặc giữa các SW component và BSW. RTE mã hóa kết nối giữa các SW component đã được thiết kế ở giai đoạn VFB để có thể triển khai trên bộ điều khiển. Nói cách khác, RTE có thể được coi là việc triển khai VFB ở cấp độ mã.
Cuối cùng, dự án sẽ được biên dịch để tạo ra phần mềm mục tiêu (Generation).

XEM THÊM : Autosar

Tổng quan về nền tảng AUTOSAR và kỹ thuật phần mềm ô tô

Bởi

eiovn

11 Tháng 11, 2024

AUTOSAR là lớp trung gian kết nối giữa Application SW và HW

Nền tảng AUTOSAR

Nền tảng AUTOSAR là viết tắt của AUTomotive Open System ARchitecture, có nghĩa là kiến trúc hệ thống mở cho ô tô. Hệ thống mở là kiến trúc mà bất kỳ nhà sản xuất ô tô hoặc nhà cung cấp linh kiện nào cũng có thể sử dụng. Nền tảng AUTOSAR này là tiêu chuẩn phần mềm ô tô được thiết lập bởi liên minh AUTOSAR.

Giới thiệu về nền tảng phần mềm tiêu chuẩn ô tô, AUTOSAR.

Liên minh AUTOSAR được thành lập với mục tiêu tiêu chuẩn hóa nền tảng phần mềm điện tử trên ô tô, bao gồm các nhà sản xuất ô tô và nhà cung cấp linh kiện. Liên minh có khẩu hiệu “Hợp tác về tiêu chuẩn, Cạnh tranh về thực hiện”. Khẩu hiệu này có nghĩa là các thành viên sẽ hợp tác để xây dựng các tiêu chuẩn, trong khi vẫn cạnh tranh trong việc thực hiện và triển khai các tiêu chuẩn đó.
Với xu hướng điện hóa và tự lái trong ngành ô tô, hệ thống điện tử (E/E) trong xe đang gia tăng một cách nhanh chóng, điều này làm nổi bật sự cần thiết phải thiết lập các tiêu chuẩn kiến trúc.
Nói một cách đơn giản, tiêu chuẩn hóa có nghĩa là cung cấp giao diện để trừu tượng hóa. Trừu tượng hóa có nghĩa là mặc dù không biết chi tiết nội dung bên trong cách thức hoạt động của chức năng, nhưng vẫn có thể thực hiện chức năng đó thông qua một giao diện đã được định nghĩa trước.

Trong xe ô tô, có nhiều chức năng và giao diện khác nhau. Tuy nhiên, hầu hết các chức năng cơ bản như phanh, lái đều không thay đổi theo nhà sản xuất ô tô. Những chức năng này đã được tiêu chuẩn hóa trong ngành công nghiệp ô tô. Ví dụ, bất kể xe của nhà sản xuất nào, người lái vẫn có thể thực hiện các chức năng của xe thông qua cùng một giao diện như bàn đạp ga hoặc vô lăng. Dù các bộ phận bên trong xe như hệ thống truyền động, phanh, lái có thể khác nhau, nhưng hiệu suất sẽ khác nhau tùy theo từng nhà sản xuất. Đây chính là ý nghĩa của “Hợp tác về tiêu chuẩn, Cạnh tranh về thực hiện”.
Còn về tiêu chuẩn hóa phần mềm cho kỹ thuật phần mềm ô tô thì sao? Tiêu chuẩn hóa phần mềm có nghĩa là định nghĩa giao diện, tức là xác định tên, chức năng, và giá trị trả về của các hàm. Ví dụ, trong ngôn ngữ C, các giao diện API tiêu chuẩn như hàm printf và scanf đã được tiêu chuẩn hóa và sử dụng sẵn. AUTOSAR cung cấp các giao diện để trừu tượng hóa tất cả các chức năng trong xe. Do đó, trong tài liệu SPEC của AUTOSAR, tên và chức năng của các hàm cần được định nghĩa đều được mô tả rõ ràng.

AUTOSAR nâng cao khả năng tái sử dụng phần mềm dựa trên tiêu chuẩn hóa. Bằng cách sử dụng AUTOSAR, phần mềm có thể được sử dụng độc lập với phần cứng. Việc này cho phép phần mềm có thể được chuyển giao mà không phụ thuộc vào phần cứng, giúp giảm chi phí sản xuất ô tô và tạo ra nền tảng cho sự đổi mới trong hệ thống điện tử ô tô nhằm nâng cao hiệu suất và an toàn.
AUTOSAR được thiết lập với các mục tiêu sau:

• Standardization: Tiêu chuẩn hóa hệ thống
• Scalability: Tính mở rộng của dự án
• Transferability: Tính chuyển giao chức năng
• Integration: Tích hợp dự án từ nhiều nhà cung cấp khác nhau
• Maintainability: Dễ dàng bảo trì theo chu kỳ sản xuất
• COTS (Commercial Off The Shelf hardware): Phần cứng thương mại sẵn có
• SW cập nhật (OTA, Over The Air): Cập nhật phần mềm qua mạng
• Safety Requirements: Các yêu cầu an toàn
• Redundancy: Độ dự phòng

Main Concept: Architecture (Kiến trúc)

AUTOSAR là lớp trung gian kết nối giữa Application SW và HW. Nó cung cấp các giao diện tiêu chuẩn và các mô-đun chức năng chung (Functional Module), cho phép thực hiện phần mềm độc lập với phần cứng (Hardware Independent Software Applications).

Main Concept : Methodology

Định nghĩa phương pháp phát triển bằng cách sử dụng định dạng lưu trữ (Exchange Format, trong AUTOSAR sử dụng ARXML) hoặc mẫu mô tả (Description Template). Điều này giúp tạo ra sự giao tiếp rõ ràng giữa nhà sản xuất ô tô và nhà cung cấp.

Khái niệm chính: Giao diện ứng dụng

Trong AUTOSAR, tất cả các giao tiếp giữa các SW component được thực hiện thông qua các giao diện đã được định nghĩa sẵn. Việc giao tiếp trực tiếp giữa dữ liệu hoặc dịch vụ của các SW component là không thể. AUTOSAR sử dụng ba loại giao diện như sau:

1. Giao diện AUTOSAR
2. Giao diện tiêu chuẩn hóa AUTOSAR
3. Giao diện tiêu chuẩn hóa.

XEM THÊM : Blog Autosar

RTE sự kiện AUTOSAR (Event Management)

Bởi

eiovn

6 Tháng 11, 2024

RTE sự kiện AUTOSAR

Ngoài các API giao tiếp, RTE còn cung cấp các API cho việc quản lý sự kiện trong SWC(RTE sự kiện AUTOSAR), chẳng hạn như:
a. Rte_Trigger_<PortName>_<EventName>
• Mục đích: Kích hoạt một sự kiện (Event) trong một SWC.
• Cú pháp:

Std_ReturnType Rte_Trigger_<PortName>_<EventName>();
• Tham số:
o PortName: Tên của Port.
o EventName: Tên của sự kiện cần kích hoạt.
• Ví dụ:

Rte_Trigger_AlarmControl_AlarmEvent();
Ví dụ này kích hoạt một sự kiện AlarmEvent trong SWC qua Port AlarmControl.

b. Rte_IrvWrite_<VariableName>
• Mục đích: Ghi dữ liệu vào một biến cục bộ của SWC (Inter-Runnable Variable).
• Cú pháp:

void Rte_IrvWrite_<RunnableName>_<VariableName>(DataType value);
• Ví dụ:

Rte_IrvWrite_RunMotorControl_MotorSpeed(speed);
Trong ví dụ này, tốc độ của motor được lưu vào một biến cục bộ có tên MotorSpeed của runnable RunMotorControl.
c. Rte_IrvRead_<VariableName>
• Mục đích: Đọc giá trị từ một biến cục bộ của SWC.
• Cú pháp:

DataType Rte_IrvRead_<RunnableName>_<VariableName>();
• Ví dụ:

motorSpeed = Rte_IrvRead_RunMotorControl_MotorSpeed();
Trong ví dụ này, SWC đọc giá trị MotorSpeed từ runnable RunMotorControl

RTE API giao tiếp Client-Server (C/S Communication)

Bởi

eiovn

6 Tháng 11, 2024

RTE API cho giao tiếp Client-Server

Loại giao tiếp này dựa trên mô hình yêu cầu-dịch vụ, trong đó một Client SWC yêu cầu một dịch vụ từ một Server SWC. Các API phổ biến cho loại giao tiếp này bao gồm:

a. Rte_Call_<PortName>_<OperationName>

• Mục đích: Client SWC gọi một dịch vụ từ Server SWC thông qua Client Port.
• Cú pháp:
Std_ReturnType Rte_Call_<PortName>_<OperationName>([input parameters]);
• Tham số:

o PortName: Tên của Client Port.
o OperationName: Tên của dịch vụ (Operation) mà SWC cần gọi.
o [input parameters]: Các tham số cần thiết cho dịch vụ.

• Kết quả trả về: Hàm trả về E_OK nếu lời gọi thành công, hoặc E_NOT_OK nếu có lỗi xảy ra.
• Ví dụ:
Rte_Call_EngineControl_StartEngine();
Trong ví dụ này, Client SWC yêu cầu Server SWC thực hiện dịch vụ StartEngine thông qua Client Port EngineControl.
b. Rte_Result_<PortName>_<OperationName>

• Mục đích: Dùng để lấy kết quả từ một dịch vụ đã được yêu cầu từ Server.
• Cú pháp:
Std_ReturnType Rte_Result_<PortName>_<OperationName>([output parameters]);
• Tham số:

o PortName: Tên của Server Port.
o OperationName: Tên của dịch vụ đã được gọi.
o [output parameters]: Các tham số đầu ra từ dịch vụ.

• Ví dụ:
Rte_Result_EngineControl_GetEngineStatus(&engineStatus);
Trong ví dụ này, Client SWC lấy kết quả trạng thái động cơ từ Server SWC thông qua Port EngineControl.

#RTE API giao tiếp Client-Server

RTE API cho giao tiếp Sender-Receiver (S/R Communication)

Bởi

eiovn

6 Tháng 11, 2024

RTE API cho giao tiếp Sender-Receiver

Loại giao tiếp này liên quan đến việc gửi và nhận dữ liệu giữa các SWC thông qua các Sender Ports và Receiver Ports. Các API của RTE cho loại giao tiếp này thường là:

a. Rte_Write_<PortName>_<DataElementName>

• Mục đích: Dùng để gửi dữ liệu từ một SWC (Sender) qua một Sender Port.
• Cú pháp:
Std_ReturnType Rte_Write_<PortName>_<DataElementName>(const DataType *data);
• Tham số:

o PortName: Tên của Sender Port.
o DataElementName: Tên của phần tử dữ liệu mà SWC gửi đi.
o data: Con trỏ tới dữ liệu mà bạn muốn gửi.

• Kết quả trả về: Hàm này trả về E_OK nếu dữ liệu được gửi thành công, hoặc E_NOT_OK nếu có lỗi xảy ra.
• Ví dụ:
Rte_Write_TemperatureSensor_TemperatureValue(&temperature);
Trong ví dụ này, SWC gửi một giá trị nhiệt độ thông qua Sender Port TemperatureSensor và phần tử dữ liệu TemperatureValue.
b. Rte_Read_<PortName>_<DataElementName>
• Mục đích: Dùng để nhận dữ liệu từ một Receiver Port.
• Cú pháp:
Std_ReturnType Rte_Read_<PortName>_<DataElementName>(DataType *data);
• Tham số:

o PortName: Tên của Receiver Port.
o DataElementName: Tên của phần tử dữ liệu mà SWC sẽ nhận.
o data: Con trỏ tới biến mà dữ liệu nhận sẽ được lưu trữ.

• Kết quả trả về: Hàm trả về E_OK nếu dữ liệu được nhận thành công, hoặc E_NOT_OK nếu có lỗi xảy ra.
• Ví dụ:

Rte_Read_TemperatureDisplay_TemperatureValue(&displayedTemperature);

Trong ví dụ này, SWC nhận dữ liệu nhiệt độ thông qua Receiver Port TemperatureDisplay và lưu dữ liệu vào biến displayedTemperature.

Kiến trúc của nền tảng AUTOSAR: ASW, RTE, BSW, Dịch vụ, EAL, MCAL, CDD

Bởi

eiovn

5 Tháng 11, 2024

Kiến trúc của nền tảng AUTOSAR

Trong trang này, chúng ta sẽ xem xét kiến trúc của nền tảng AUTOSAR. AUTOSAR là một nền tảng tiêu chuẩn hóa (Standardized) và mở (Openly). Từ “tiêu chuẩn” có nghĩa là các tên hàm, chức năng, giá trị trả về, v.v. đã được định nghĩa trước, trong khi từ “mở” có nghĩa là bất kỳ ai cũng có thể sử dụng nền tảng này.

Nền tảng AUTOSAR

có cấu trúc kiến trúc phân lớp (Layered Architecture) và chủ yếu bao gồm ba thành phần từ trên xuống dưới là ASW, RTE, và BSW. Các lớp dưới cung cấp một mức độ trừu tượng nhất định cho lớp trên.

Việc tách biệt các lớp giúp cho việc duy trì hệ thống trở nên dễ dàng hơn. Ngoài ra, với cấu trúc phân lớp, việc phát triển phần mềm độc lập với phần cứng trở nên khả thi, và điều này cũng nâng cao khả năng tái sử dụng và mở rộng. Tuy nhiên, hầu hết mã nguồn có thể chỉ thực hiện vai trò truyền dữ liệu, dẫn đến việc quy mô dự án có thể trở nên quá lớn.
Trong AUTOSAR, tất cả các thành phần ECU đều được trừu tượng hóa và được chia thành các lớp Application, BSW, và HW Layer.

ASW, Application Software

Tập hợp các SWC, Software Component. SWC là đơn vị thực thi độc lập và được phân loại theo chức năng thành ứng dụng, actuator, và cảm biến.

RTE, Runtime Environment

RTE chịu trách nhiệm kết nối các thành phần Application với BSW trong khi trao đổi dữ liệu và kiểm soát sự tương tác.
Nó là môi trường thực hiện cấu trúc giao tiếp VFB. RTE cung cấp ánh xạ giao diện cho việc giao tiếp giữa các SWC trong ASW và giữa SWC với BSW một cách độc lập với ECU.

BSW, Basic Software

BSW được chia thành ba phần: Service Layer, EAL, và MCAL.

Service Layer

Service Layer là lớp cao nhất trong BSW. Trong khi việc truy cập phần cứng I/O được quản lý bởi lớp trừu tượng ECU, Service Layer cung cấp nhiều chức năng nền tảng để điều khiển hệ thống và các mô-đun trong BSW như sau:

• OS (Operating System)
• Quản lý lịch trình
• Giao tiếp và quản lý mạng
• Quản lý bộ nhớ
• Dịch vụ chẩn đoán
• Quản lý trạng thái ECU
• Watchdog

OS cần phải kiểm soát phần cứng trực tiếp để đạt hiệu quả cao, do đó Service Layer kéo dài xuống tận lớp MCAL. Đáng chú ý, AUTOSAR OS là tiêu chuẩn hệ điều hành dành cho xe hơi, mở rộng từ hệ điều hành OSEK/VDX với các tính năng bảo vệ hệ thống, lập lịch thời gian thực và xử lý bộ đếm thời gian.
EAL :: ECU Abstraction Layer.

EAL là lớp trừu tượng ECU, cung cấp giao diện cho các driver MCAL đến các lớp trên. Khi các thiết bị ngoại vi như cảm biến và actuator được kết nối với ECU, nó cung cấp cùng một giao diện cho ASW mà không cần thay đổi mạch phần cứng. EAL trừu tượng hóa tất cả các thành phần cơ bản của ECU. Các driver cho các thiết bị ngoại vi cũng nằm trong lớp này. Đáng lưu ý, ECU có phạm vi rộng hơn so với MCU.
EAL cung cấp API độc lập với phần cứng (Programming Interface). Ở đây, phần cứng bao gồm cả bên trong và bên ngoài của vi điều khiển. Nó cung cấp giao diện cho driver của các thiết bị ngoại vi và các thiết bị bên trong và bên ngoài (I/O, bộ nhớ, watchdog, giao tiếp).
MCAL :: Microcontroller Abstraction Layer

MCAL là lớp thấp nhất trong nền tảng AUTOSAR. Nó được phát triển phụ thuộc vào vi điều khiển (MCU) và cung cấp API Device Driver để khai thác tài nguyên hoặc chức năng của MCU cho các lớp trên. MCAL có thể được phân biệt một cách riêng biệt với BSW trong một số trường hợp. Nó bao gồm driver cho vi điều khiển, driver cho bộ nhớ, giao tiếp và driver I/O.
Sự tồn tại của lớp MCAL cho phép giảm thiểu việc sửa đổi toàn bộ hệ thống khi có thay đổi phần cứng, bằng cách chỉ cần chỉnh sửa phần MCAL.
CDD :: Complex Device Driver.

CDD được sử dụng để điều khiển các cảm biến hoặc actuator có điều kiện thời gian đặc biệt hoặc không có mô-đun được định nghĩa trong AUTOSAR. Qua CDD, có thể truy cập trực tiếp vào vi điều khiển để điều khiển các cảm biến hoặc actuator.
Mô-đun phần mềm AUTOSAR.

Nền tảng AUTOSAR có nhiều mô-đun khác nhau. Giao diện được sử dụng trong từng mô-đun được định nghĩa trong các tài liệu kỹ thuật riêng biệt. Khi phát triển phần mềm Application SW, các nhà phát triển tìm kiếm và sử dụng giao diện cần thiết từ các tài liệu kỹ thuật của nền tảng AUTOSAR.

Khung đo lường ASPICE và cấp độ năng lực quy trình (CL, Cấp độ Năng lực)

Bởi

eiovn

5 Tháng 11, 2024

Khung đo lường ASPICE

Việc đánh giá khả năng thực hiện quy trình dựa trên khung đánh giá hai chiều sử dụng Mô hình Đánh giá Quy trình (PAM, Process Assessment Model). Trang này sẽ nói về khung đo lường nằm trên trục y của khung này. Khung đo lường được phân tách theo các thuộc tính quy trình, mức độ khả năng (CL, Capability Level), v.v., để cung cấp các yêu cầu và quy tắc cần thiết cho quy trình.

Khung đo lường bao gồm các quy tắc đánh giá quy trình là cấp độ năng lực quy trình (CL, Cấp độ Năng lực). Thông qua đó, các đánh giá viên sẽ đưa ra cấp độ năng lực cuối cùng của quy trình. Cấp độ năng lực đề cập đến tập hợp các thuộc tính quy trình cùng hoạt động để cải thiện đáng kể khả năng thực hiện quy trình.

Như sẽ được giải thích dưới đây, các thuộc tính của các quy trình được bao gồm trong cấp độ năng lực chỉ ra từng bước trong việc cải tiến khả năng quy trình. Do đó, cấp độ năng lực trở thành một phương pháp hợp lý để đánh giá tiến độ cải tiến quy trình.
Ngoài ra, khung đo lường cung cấp các thuộc tính quy trình (Process Attribute) xác định yêu cầu quy trình. Thông qua các thuộc tính của quy trình, có thể đánh giá mức độ đạt được của cấp độ năng lực quy trình.

Cấp độ Năng lực Quy trình

Cấp độ Năng lực (Capability Level) được phân loại thành 6 cấp độ sau. Mức yêu cầu chung của các OEM ô tô thường là đến CL3.

• CL0. Quy trình chưa hoàn chỉnh
Quy trình chưa được triển khai hoặc không đạt được mục tiêu của quy trình, trong trạng thái không hoàn chỉnh.
• CL1. Quy trình thực hiện
CL0 + Thực hiện quy trình (Base Practices)
Quy trình đã được triển khai đạt được mục tiêu của quy trình.
• CL2. Quy trình quản lý
CL1 + Quản lý thực hiện (Process Management), Quản lý sản phẩm đầu ra (Work Product Management)
Việc thực hiện quy trình được kiểm soát (lập kế hoạch, quản lý, điều chỉnh), các vai trò được xác định và kết quả được thiết lập, kiểm soát và duy trì một cách thích hợp theo QA và CM.
• CL3. Quy trình đã thiết lập
CL2 + Định nghĩa quy trình (Process Definition), Triển khai quy trình (Process Deployment)
Có các quy trình chuẩn ở cấp tổ chức và hướng dẫn điều chỉnh (Tailoring), với việc cải thiện tài sản chuẩn thông qua phản hồi ở cấp tổ chức.
• CL4. Quy trình có thể dự đoán
• CL5. Quy trình đổi mới

Đánh giá thuộc tính quy trình

Khung đo lường cung cấp thang đo (Rating Scale) và các phương pháp tính toán cấp độ (Rating Method) để đánh giá mức độ đạt được của quy trình.
Các thuộc tính quy trình là thang đo để đánh giá cấp độ năng lực (Capability Level). Thang đánh giá thuộc tính quy trình (Attribute Scale) là mức độ đánh giá dựa trên mức độ đạt được của mục tiêu quy trình được xác định trong mô hình tham chiếu.

Mức độ năng lực đạt được bởi quy trình cần được suy ra từ các cấp độ thuộc tính quy trình theo mô hình cấp độ năng lực quy trình được định nghĩa trong bảng 16.
Mô hình cấp độ năng lực quy trình định nghĩa các quy tắc về cách đánh giá mức độ đạt được của từng cấp độ năng lực và các thuộc tính quy trình của tất cả các cấp độ con.
Thông thường, việc đạt được mức độ năng lực quy trình nhất định yêu cầu phải đạt được hầu hết các thuộc tính quy trình hoặc hoàn thành các thuộc tính quy trình con.

(Ví dụ) Cấp độ Năng lực SYS.2
SYS.2 – Phân tích yêu cầu hệ thống (System Requirements Analysis) về Cấp độ Năng lực
CL1. Quy trình thực hiện (Performed Process)
Nhóm dự án phát triển yêu cầu hệ thống thông qua các hoạt động cần thiết nào đó.
• Phân tích yêu cầu hệ thống

→ Soạn thảo và theo dõi yêu cầu hệ thống
→ Rà soát và phân phối yêu cầu hệ thống
→ Thể hiện năng lực Kỹ thuật phần mềm (Software Engineering)

• Quy trình không có tính hệ thống, nhưng mục tiêu được đạt và có sản phẩm đầu ra nhất định.
• Nhận thức được mục tiêu cần đạt nhưng không thể lập kế hoạch một cách hệ thống.
• Các biện pháp tạm thời được thực hiện để giải quyết vấn đề phát sinh.
• Phản ứng thứ cấp dựa trên kết quả của các biện pháp.

CL2. Quy trình quản lý (Managed Process)
Thực hiện các hoạt động theo kế hoạch và tiến hành bảo đảm chất lượng và quản lý hình dạng (Configuration Management) đối với quá trình và kết quả.
• Kế hoạch dự án, WBS, Tiêu chí chất lượng, Báo cáo rà soát, Kết quả giám sát, Kho lưu trữ quản lý hình dạng.
→ Trạng thái có thể thực hiện liên tục quy trình trong nhóm dự án.

• Nhận thức được mục tiêu và các ràng buộc của quy trình.
• Lập chiến lược đạt mục tiêu dưới các ràng buộc.
• Hoàn tất các chuẩn bị cần thiết theo chiến lược.
• Các thành viên trong nhóm cùng hành động theo chiến lược.
• Thiết lập các biện pháp thích hợp cho những trở ngại so với kế hoạch.

CL3. Quy trình đã thiết lập (Established Process)
Quyết định các hoạt động sẽ thực hiện bằng cách nào dựa trên tài sản tiêu chuẩn và tiến hành phản hồi trong quá trình thực hiện quy trình.
• Tài sản quy trình tiêu chuẩn, Tiêu chí điều chỉnh (Tailoring) và kết quả, Phản hồi từ kết quả áp dụng.
→ Trạng thái có thể thực hiện liên tục quy trình trong tổ chức.

• Định nghĩa các tiêu chuẩn để đạt được mục tiêu.
• Lập kế hoạch để thực hiện tiêu chuẩn.
• Điều chỉnh một cách thích hợp theo tình huống để thực hiện.
• Quan sát kết quả thực hiện và bổ sung tiêu chuẩn.

Mô hình tham chiếu quy trình ASPICE (PRM, Process Reference Model) và phạm vi bắt buộc VDA

Bởi

eiovn

4 Tháng 11, 2024

Mô hình tham chiếu quy trình ASPICE trong ô tô

Xác định khả năng quy trình

Việc đánh giá khả năng thực hiện quy trình dựa trên khung đánh giá hai chiều sử dụng Mô hình Đánh giá Quy trình (PAM, Process Assessment Model). Đầu tiên, một chiều của khung hai chiều này là Mô hình Tham chiếu Quy trình (PRM, Process Reference Model), định nghĩa quy trình dựa trên các yếu tố như phạm vi và lĩnh vực của quy trình. Chiều còn lại là Khung Đo lường (Measurement Framework), được sử dụng để đo lường quy trình theo các thuộc tính quy trình, mức độ khả năng (CL, Capability Level), và các yếu tố khác.
Thông qua Mô hình Tham chiếu Quy trình, ta định nghĩa quy trình cần thực hiện, sau đó sử dụng khung đo lường chi tiết để đánh giá quy trình. Trong quá trình này, người đánh giá thu thập bằng chứng khách quan để có thể gán mức độ khả năng cho quy trình.

• Mô hình Tham chiếu Quy trình: Phạm vi, lĩnh vực, mục đích và kết quả của quy trình.
• Khung Đo lường: Thuộc tính quy trình, mức độ khả năng, và xếp hạng.

Mô hình Tham chiếu Quy trình

Quy trình được nhóm lại trước tiên theo Danh mục Quy trình (Process Categories). Tiếp theo, chúng được nhóm vào các nhóm quy trình dựa trên loại hoạt động (Activity) mà quy trình thực hiện. Mỗi quy trình được mô tả dựa trên phần mô tả mục tiêu của nó. Phần mô tả mục tiêu bao gồm các mục tiêu chức năng riêng khi quy trình được thực hiện trong một môi trường cụ thể.
Quy trình có 3 danh mục chính như sau:

• Primary Life Cycle Process (Màu đỏ)
• Organizational Life Cycle Process (Màu xanh lam)
• Supporting Life Cycle Process (Màu xanh lục)

Primary Life Cycle Processes

Danh mục Primary Life Cycle Process bao gồm các quy trình kỹ thuật cần thiết cho việc đặc tả (Specification), thiết kế (Design), phát triển (Development), tích hợp (Integration), và kiểm thử (Testing), cùng với các quy trình được sử dụng khi nhận bàn giao sản phẩm từ nhà cung cấp. Ngoài ra, nó còn bao gồm các quy trình được nhà cung cấp sử dụng khi cung cấp sản phẩm đầu ra và phản hồi cho khách hàng.

• Acquisition Process Group: Nhóm quy trình để bàn giao sản phẩm
• Supply Process Group: Nhóm quy trình để cung cấp sản phẩm đầu ra
• System Engineering Process Group: Nhóm quy trình phát triển hệ thống
• Software Engineering Process Group: Nhóm quy trình phát triển phần mềm

System Engineering Process Group

Organizational Life Cycle Processes

Danh mục Organizational Life Cycle Process bao gồm các quy trình để phát triển Quy trình (Process), Sản phẩm (Product), Tài nguyên (Resource), v.v. Những quy trình này được sử dụng trong nhiều dự án khác nhau trong tổ chức và giúp tổ chức đạt được các mục tiêu kinh doanh.

• Management Process Group: Nhóm quy trình quản lý quy trình
• Process Improvement Process Group: Nhóm quy trình vòng đời tổ chức
• Reuse Process Group: Nhóm quy trình cần được thực hiện trên nhiều tổ chức

Supporting Life Cycle Processes

Danh mục Supporting Life Cycle Process bao gồm các quy trình có thể được sử dụng bởi các quy trình khác. Nói cách khác, đây là nhóm quy trình hỗ trợ để đảm bảo các nhóm quy trình khác hoạt động suôn sẻ.

• Support Process Group: Nhóm quy trình hỗ trợ vòng đời

Các quy trình bắt buộc phải tuân thủ

Liệu có cần phải tuân thủ tất cả các quy trình này (tổng cộng 32 quy trình) không?
Không phải vậy. VDA đã chỉ định 16 quy trình phải tuân thủ bắt buộc. Ngoài ra, tùy theo nội dung dự án, phạm vi các quy trình áp dụng có thể được điều chỉnh theo thỏa thuận với OEM.
Trong hình trên, các quy trình được đánh dấu bằng viền đỏ là những quy trình mà VDA quy định phải thực hiện. Điều này được gọi là VDA Scope. Trước đây, nó được gọi là HIS Scope

10 quy trình liên quan đến phát triển
Nhóm quy trình kỹ thuật hệ thống (SYS) bao gồm các quy trình liên quan đến việc rút ra và quản lý yêu cầu từ khách hàng và yêu cầu nội bộ, xác định kiến trúc hệ thống, cũng như thực hiện tích hợp và kiểm thử ở cấp độ hệ thống.
Nhóm quy trình kỹ thuật phần mềm (SWE) bao gồm các quy trình liên quan đến quản lý yêu cầu phần mềm được rút ra từ yêu cầu hệ thống, phát triển kiến trúc và thiết kế phần mềm, thực hiện phần mềm, cũng như tích hợp và kiểm thử.
(Phía trái) Phân tích, thiết kế (Phía phải) – Xác minh

2 quy trình ở cấp độ tổ chức
Nhóm quy trình hỗ trợ vòng đời (SUP) bao gồm các quy trình có thể được sử dụng bởi các quy trình khác ở nhiều thời điểm trong vòng đời.

• Quản lý Dự án (Project Management)
• Giám sát Nhà cung cấp (Supplier Monitoring)

4 quy trình hỗ trợ
Nhóm quy trình vòng đời (MAN) bao gồm các quy trình để phát triển quy trình, sản phẩm và tài sản nguồn lực. Những quy trình này giúp tổ chức đạt được các mục tiêu kinh doanh khi được sử dụng trong nhiều dự án khác nhau trong tổ chức.

• Đảm bảo chất lượng (Quality Assurance)
• Quản lý cấu hình (Configuration Management)
• Quản lý giải quyết vấn đề (Problem Resolution Management)
• Quản lý yêu cầu thay đổi (Change Request Management)

Chế độ an toàn chức năng của xe: Hệ thống Failsafe và Hệ thống Fail-Operational

1...678 9 Trang 7 của 9

Autosar là gì ?

Điều kiện học Autosar ban đầu

Application Layer

AUTOSAR RTE

Services Layer

ECU Abstraction Layer

Lý do phải có Autosar

Dưới đây là một số khó khăn thường gặp khi phát triển phần mềm cho ECU:

Đây không phải là một hạn chế vì AUTOSAR đã cung cấp tất cả các trình điều khiển và lớp cần thiết rồi sao?

Nếu tôi sử dụng thiết bị ngoại vi bên ngoài mà AUTOSAR không hỗ trợ thì có vấn đề gì không?

Các loại AUTOSAR

Quy Trình Phát Triển Autosar

AUTOSAR có thể gây khó khăn cho các nhà phát triển mới, do đó phần này sẽ giới thiệu về việc bắt đầu với dự án sử dụng AUTOSAR.

Một số bước trong quá trình cấu hình bao gồm

AUTOSAR RTE Runtime Environment

Kiến trúc AUTOSAR được phân chia thành ba phần chính

Tầng ứng dụng

Phần mềm Cơ bản (BSW)

Môi trường Thực thi AUTOSAR (RTE)

Giao diện Virtual Function Bus (VFB)

Bắt đầu thảo luận về cách thiết kế RTE và trách nhiệm của nó

Tình huống ví dụ

Phương pháp AUTOSAR

Phương pháp AUTOSAR: Là quy trình phát triển chung được định nghĩa trong AUTOSAR

Application SW:

VFB: Virtual Functional Bus.

Ánh xạ ECU: Phân bổ bộ điều khiển.

RTE: Run-Time Environment.

Nền tảng AUTOSAR

Giới thiệu về nền tảng phần mềm tiêu chuẩn ô tô, AUTOSAR.

Main Concept: Architecture (Kiến trúc)

Main Concept : Methodology

Khái niệm chính: Giao diện ứng dụng

RTE sự kiện AUTOSAR

RTE API cho giao tiếp Client-Server

RTE API cho giao tiếp Sender-Receiver

Kiến trúc của nền tảng AUTOSAR

Nền tảng AUTOSAR

ASW, Application Software

RTE, Runtime Environment

BSW, Basic Software

Khung đo lường ASPICE

Cấp độ Năng lực Quy trình

Đánh giá thuộc tính quy trình

Mô hình tham chiếu quy trình ASPICE trong ô tô

Xác định khả năng quy trình

Mô hình Tham chiếu Quy trình

Primary Life Cycle Processes

Organizational Life Cycle Processes

Supporting Life Cycle Processes

Các quy trình bắt buộc phải tuân thủ

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