[{"content":"Ở các bài trước, chúng ta đã làm quen với kiến trúc phân lớp của AUTOSAR, các loại software component, và RTE — lớp kết nối mọi thứ lại với nhau. Bây giờ đã đến lúc trả lời câu hỏi tự nhiên tiếp theo: các software component thực sự giao tiếp với nhau như thế nào?\nCâu trả lời nằm ở Ports và Port Interfaces — các điểm kết nối chính thức, được chuẩn hóa mà AUTOSAR định nghĩa cho mọi luồng dữ liệu hoặc service đi qua giữa các component. Bài học này sẽ phân tích toàn bộ vấn đề một cách rõ ràng, từ các loại port cơ bản đến hai interface phổ biến nhất mà bạn sẽ gặp trong các dự án thực tế.\nI. Port là gì? Một Port là điểm kết nối cho việc giao tiếp giữa các software component (SWC). Hãy hình dung nó như một ổ cắm điện: một phía cung cấp điện (provider), phía kia tiêu thụ (requirer). Mọi trao đổi dữ liệu hoặc service giữa các component đều nên đi qua port — không nên kết nối trực tiếp (extern) trong AUTOSAR.\nAUTOSAR định nghĩa ba loại port:\nProvider Port (P-Port): Bên gửi / cung cấp thông tin hoặc service cho các component khác. Requirer Port: (R-Port): Nhận / yêu cầu thông tin hoặc service từ provider. Provider-Requirer Port (PR-Port): Hai chiều: vừa gửi vừa nhận cùng một thông tin đồng thời. II. Port Interfaces. Một port chỉ đơn thuần là điểm kết nối. Port Interface định nghĩa loại thông tin, dữ liệu thực sự chạy qua đó. AUTOSAR quy định 6 loại interface:\nSender/Receiver Interface. Dùng để truyền dữ liệu — biến thuộc bất kỳ kiểu nào (integer, float, struct, array\u0026hellip;). Sender đẩy dữ liệu đi mà không chờ phản hồi. Receiver sử dụng dữ liệu khi cần. Đây là loại interface phổ biến nhất trong các dự án thực tế.\nGiao tiếp: bất đồng bộ (asynchronous) Topology: 1:1, 1:N, M:1 — nhưng KHÔNG cho phép M:N Ứng dụng điển hình: chia sẻ giá trị cảm biến, kết quả tính toán, cờ trạng thái. Client/Server Interface. NV Data Interface. Parameter Interface. Mode Switch Interface. Trigger Interface. ","permalink":"https://embedded-lab.pages.dev/posts/bai-4-port-and-interfaces/","summary":"\u003cp\u003eỞ các bài trước, chúng ta đã làm quen với kiến trúc phân lớp của AUTOSAR, các loại software component, và RTE — lớp kết nối mọi thứ lại với nhau. Bây giờ đã đến lúc trả lời câu hỏi tự nhiên tiếp theo: các software component thực sự giao tiếp với nhau như thế nào?\u003c/p\u003e\n\u003cp\u003eCâu trả lời nằm ở Ports và Port Interfaces — các điểm kết nối chính thức, được chuẩn hóa mà AUTOSAR định nghĩa cho mọi luồng dữ liệu hoặc service đi qua giữa các component. Bài học này sẽ phân tích toàn bộ vấn đề một cách rõ ràng, từ các loại port cơ bản đến hai interface phổ biến nhất mà bạn sẽ gặp trong các dự án thực tế.\u003c/p\u003e","title":"Bài 4: Port and Interfaces"},{"content":"Ở các bài trước, chúng ta đã khám phá kiến trúc phân lớp của AUTOSAR và cách RTE (Runtime Environment) đóng vai trò là ranh giới rõ ràng giữa Application Software (ASW) và Basic Software (BSW). Trong bài này, chúng ta sẽ đi sâu hơn vào Application Software Layer và trả lời câu hỏi: Layer này thực sự chứa gì, và chúng ta thiết kế nó như thế nào?\nCâu trả lời nằm ở Software Component (SW-C) — những khối xây dựng cơ bản của bất kỳ ứng dụng AUTOSAR nào.\nI. Software Component Là Gì? ASW layer trong AUTOSAR được tổ chức thành các đơn vị độc lập gọi là Atomic Software Component Types. Mỗi atomic software component type đại diện cho một phần chức năng cụ thể trong ứng dụng.\nHãy tưởng tượng các software component như những mảnh LEGO: mỗi mảnh làm một việc riêng, và khi ghép lại, chúng tạo thành một hệ thống hoàn chỉnh.\nCác software component được chia thành ba nhóm chính:\nAtomic Software Component Types (7 loại cụ thể — trọng tâm của bài này). Parameter Component. Composition Software Component Type. II. 7 Loại Atomic Software Component. 2.1 Application Software Component (AppSWC). Đây là loại component được sử dụng phổ biến nhất. Nó là component tổng quát, dùng để chứa logic chức năng cốt lõi của ứng dụng — như tính toán, ra quyết định, và các thuật toán điều khiển.\nVí dụ thực tế: Hệ thống start/stop tự động. Thuật toán quyết định khi nào tắt máy và khởi động lại động cơ tự động sẽ nằm trong một Application Software Component.\n2.2 NV Block Software Component. Component này được sử dụng khi bạn cần lưu dữ liệu quan trọng vào non-volatile memory (NVM) — bộ nhớ giữ nguyên dữ liệu sau khi mất điện.\nNó hoạt động như một cầu nối giữa application layer và NVM Manager trong BSW.\nVí dụ thực tế: Đồng hồ đo quãng đường (odometer). Tổng số km đã đi phải được lưu vào NVM khi tắt nguồn và phục hồi ở lần khởi động tiếp theo. NV Block SW-C quản lý việc truyền dữ liệu này giữa ứng dụng và NVM Manager.\n2.3 Complex Device Driver (CDD) CDD là component chuyên biệt dành cho các trường hợp truy cập phần cứng yêu cầu thời gian thực — khi việc truyền tín hiệu qua nhiều lớp BSW sẽ gây ra độ trễ không thể chấp nhận được.\nNó cung cấp một đường tắt: ứng dụng có thể gửi lệnh qua RTE trực tiếp đến phần cứng mà không cần đi qua toàn bộ BSW stack.\n⚠️ Lưu ý quan trọng: RTE không bao giờ bị bypass. Mọi giao tiếp vẫn phải đi qua RTE, kể cả khi dùng CDD.\nVí dụ thực tế: Kích hoạt túi khí (airbag) hoặc ngắt kim phun nhiên liệu (fuel injector) — những thao tác mà chỉ một mili-giây trễ cũng không thể chấp nhận được.\n2.4 Service Component. Service Component được BSW layer sử dụng để cung cấp các dịch vụ (service) lên application layer. Nó tuân theo các quy tắc đặc biệt — có thể là một phần của system composition và gắn chặt với ECU level.\nVí dụ thực tế: ECU State Manager hoặc Diagnostics Event Manager là các module BSW được mô hình hóa dưới dạng Service Software Component để cung cấp chức năng cho application.\n2.5 Service Proxy Component. Component này phát huy tác dụng trong kiến trúc nhiều ECU. AUTOSAR cho phép các software component được phân bổ động lên các ECU khác nhau trong quá trình cấu hình hệ thống. Nếu một service cần thiết lại nằm trên một ECU khác, Service Proxy Component sẽ xử lý việc truy cập từ xa mà không làm thay đổi cách application sử dụng service đó.\n2.6 ECU Abstraction Software Component. Component này nằm ở giao diện giữa MCAL layer và application layer. Nó được dùng để viết driver cho các ngoại vi (peripheral) bên ngoài kết nối với vi điều khiển — ví dụ H-Bridge IC, power stage IC, và các thiết bị trên bo mạch tương tự.\nBạn có thể có nhiều ECU Abstraction component, mỗi cái cho một ngoại vi bên ngoài.\nVí dụ thực tế: Đọc dữ liệu xung thô từ cảm biến tốc độ kết nối với chân digital I/O.\n2.7 Sensor Actuator Software Component. Component này là Software Component trong AUTOSAR chịu trách nhiệm xử lý giao tiếp với các cảm biến hoặc cơ cấu chấp hành.\nNhiệm vụ của nó:\nVới sensor: chuyển đổi dữ liệu thô (ví dụ: số xung) thành giá trị kỹ thuật có ý nghĩa (ví dụ: tốc độ km/h). Với actuator: điều phối và điều khiển các cơ cấu chấp hành bên ngoài dựa trên lệnh từ application III. Parameter Software Component. Đây là loại component không có chức năng thực thi — không có file C implementation và không đóng góp logic runtime. Mục đích duy nhất của nó là cung cấp các tham số hiệu chỉnh (calibration parameters) cho các software component khác trong dự án.\nCác quy tắc đặc biệt:\nKhông có file C — chỉ là cấu hình. Không có Receiver Port — chỉ có Provider Port. Không thể thực hiện bất kỳ chức năng runtime nào. Ví dụ thực tế: Ngưỡng cường độ ánh sáng để tự động bật đèn pha. Giá trị ngưỡng này được lưu trong Parameter SW-C và có thể tinh chỉnh trong quá trình sản xuất xe mà không cần thay đổi code application.\nIV. Composition Software Component. Hãy nghĩ về đây như một container. Một Composition SW-C nhóm các software component khác (và cả các composition khác) vào một cụm logic theo chức năng.\nĐặc điểm chính:\nKhông có file C implementation riêng. Chứa cấu hình của các component bên trong và các kết nối nội bộ (Connector) giữa chúng. Có thể lồng nhau — một composition có thể chứa các composition khác. V. Software Component Exammple. Bây giờ hãy áp dụng những gì chúng ta đã học. Giả sử có chúng ta đang cần thiết kế 1 ECU có chức năng như sau:\nĐọc tốc độ xe từ một cảm biến tốc độ bên ngoài. Nếu tốc độ vượt quá ngưỡng hiệu chỉnh: Ngắt kim phun nhiên liệu (fuel injector) ngay lập tức. Ghi lỗi qua module Diagnostics. Tính toán và lưu tốc độ tối đa đạt được trong chu kỳ lái xe. Khôi phục giá trị này khi ECU được cấp nguồn lần tiếp theo. Cùng thiết kế kiến trúc software component AUTOSAR cho yêu cầu này, chúng ta sẽ liệt kê các công việc cần làm, với mỗi công việc chúng ta sẽ chọn 1 software component type phù hợp.\nCông việc Software Component Type Lý do Đọc xung thô từ cảm biến tốc độ qua chân digital I/O ECU Abstraction SW-C Giao tiếp với MCAL để đọc xung qua GPIO pin đổi xung thô thành tốc độ (km/h) Sensor Actuator SW-C Biến dữ liệu sensor thành giá trị sử dụng được cho application Logic cốt lõi: so sánh tốc độ với ngưỡng Application SW-C Thực hiện quá trình kiểm tra giá trị quy đổi từ sensor và ra quyết định Giá trị ngưỡng tốc độ cắt — có thể hiệu chỉnh Parameter SW-C Cung cấp calibration có thể tinh chỉnh trong sản xuất Ngắt injector — yêu cầu thời gian thực Complex Device Driver (CDD) Bỏ qua độ trễ của BSW layering để truy cập phần cứng ngay lập tức Ghi lỗi diagnostic Service SW-C (Diagnostics Event Manager) Cung cấp dịch vụ diagnostic cho application Lưu/phục hồi tốc độ tối đa vào/từ NVM NV Block SW-C Kết nối application với NVM Manager trong BSW VI. Tổng kết. Mô hình software component của AUTOSAR cung cấp cho các kỹ sư một bộ từ vựng rõ ràng, có cấu trúc để phân tách chức năng ứng dụng. Việc chọn đúng loại component không chỉ là về kiến trúc tốt — nó còn trực tiếp ảnh hưởng đến khả năng tái sử dụng, tính đúng đắn về thời gian, và mức độ tách biệt giữa các vấn đề phần cứng và logic ứng dụng.\nLoại Component Mục Đích Chính Application SW-C Xử lý logic chính của application NV Block SW-C Lưu trữ dữ liệu non-volatile Complex Device Driver Truy cập phần cứng trực tiếp cho tình huống time-critical Service SW-C Cung cấp BSW service cho application Service Proxy SW-C Truy cập các service giữa các ECU ECU Abstraction SW-C Driver cho peripheral bên ngoài Sensor Actuator SW-C Chuyển đổi dữ liệu sensor \u0026amp; điều khiển actuator Parameter SW-C Tham số hiệu chỉnh Composition SW-C Nhóm/container logic của các component Trong bài tiếp theo, chúng ta sẽ đi sâu hơn vào Port và Connector — các cơ chế giao tiếp kết nối tất cả các component này lại với nhau.\n","permalink":"https://embedded-lab.pages.dev/posts/bai-3-software-component/","summary":"\u003cp\u003eỞ các bài trước, chúng ta đã khám phá kiến trúc phân lớp của AUTOSAR và cách RTE (Runtime Environment) đóng vai trò là ranh giới rõ ràng giữa Application Software (ASW) và Basic Software (BSW). Trong bài này, chúng ta sẽ đi sâu hơn vào \u003cstrong\u003eApplication Software Layer\u003c/strong\u003e và trả lời câu hỏi: \u003cem\u003eLayer này thực sự chứa gì, và chúng ta thiết kế nó như thế nào?\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eCâu trả lời nằm ở \u003cstrong\u003eSoftware Component (SW-C)\u003c/strong\u003e — những khối xây dựng cơ bản của bất kỳ ứng dụng AUTOSAR nào.\u003c/p\u003e","title":"Bài 3: Software Component"},{"content":"1. Tổng Quan Kiến Trúc Phân Lớp AUTOSAR. Kiến trúc phân lớp (Layered Architecture) của AUTOSAR cung cấp toàn bộ cơ chế cần thiết để đạt được sự độc lập giữa phần mềm và phần cứng. Toàn bộ phần mềm chạy trên vi điều khiển (microcontroller) được chia thành ba lớp chính:\nASW – Application Software Layer. RTE – Runtime Environment. BSW – Basic Software. Ý tưởng cốt lõi của kiến trúc này là tách biệt hoàn toàn phần mềm ứng dụng (không phụ thuộc phần cứng) với phần mềm nền tảng (phụ thuộc phần cứng) thông qua tầng trung gian RTE.\n2. Vai Trò Của RTE – \u0026ldquo;Bức Tường Ngăn Cách\u0026rdquo; Quan Trọng RTE đóng vai trò như một lớp trừu tượng hóa rõ ràng:\nPhía trên RTE: hoàn toàn độc lập với phần cứng. Nhờ đó, các nhà phát triển có thể xây dựng phần mềm ứng dụng cạnh tranh mà không cần lo về loại chip hay board mạch sử dụng. Phía dưới RTE: cho phép chuẩn hóa và phát triển BSW độc lập với ứng dụng. Các lập trình viên BSW chỉ cần tập trung vào các đặc thù của phần cứng. Lợi ích thực tế: Một nhà sản xuất ô tô có thể tái sử dụng cùng một phần mềm ứng dụng (ví dụ: hệ thống hỗ trợ đỗ xe – Parking Assist) trên nhiều biến thể xe khác nhau với phần cứng ECU khác nhau. Chi phí phát triển chỉ bỏ ra một lần, nhưng lại được sử dụng trên nhiều dòng xe và nhiều biến thể. 3. Cấu Trúc Chi Tiết Của Basic Software (BSW). BSW được phân chia thành ba lớp con chính và một thành phần đặc biệt:\nServices Layer (Lớp dịch vụ). ECU Abstraction Layer (Lớp trừu tượng hóa ECU). MCAL – Microcontroller Abstraction Layer. Complex Device Drivers (CDD) BSW là nhóm component đã được chuẩn hóa, cung cấp các dịch vụ cho các software component phía trên. Nó không thực hiện chức năng nghiệp vụ nào của xe, mà chỉ phục vụ nền tảng. Nó chứa cả các component đã chuẩn hóa (Memory, Communication Services…) lẫn các component đặc thù ECU (OS, MCAL, Complex Device Drivers).\n3.1. MCAL – Microcontroller Abstraction Layer. MCAL là lớp thấp nhất của BSW, tiếp xúc trực tiếp với phần cứng vi điều khiển. Đây là lớp đặc thù phần cứng duy nhất, đảm bảo cung cấp các interface (API) chuẩn cho các lớp BSW bên trên.\nChức năng của MCAL:\nQuản lý các ngoại vi của vi điều khiển. Cung cấp các giá trị độc lập với vi điều khiển cho các component BSW bên trên. Thực hiện các cơ chế thông báo (notification) để phân phối lệnh, phản hồi và thông tin xử lý. MCAL được chia thành bốn nhóm driver:\\\nIO Drivers – Các driver cho ngoại vi I/O: ADC (Analog to Digital Converter). PWM (Pulse Width Modulation), ICU (Input Capture). Digital IO. Communication Drivers – Giao tiếp nội bộ và xe: Giao tiếp nội bộ ECU: SPI, I2C, UART,\u0026hellip; Giao giữa các ECU trong xe: CAN, LIN, Flexray, Ethernet\u0026hellip; Memory Drivers – Bộ nhớ: Flash nội (Internal Flash), EEPROM nội. Bộ nhớ ngoài (External Flash, External EEPROM). Microcontroller Drivers – Ngoại vi nội bộ: Watchdog, MCUvà các chức năng truy cập trực tiếp vi điều khiển. 3.2. ECU Abstraction Layer. Lớp này nằm trên MCAL, cung cấp giao diện phần mềm đến các giá trị điện học của một ECU cụ thể, giúp tách biệt các lớp phần mềm cấp cao hơn khỏi tất cả các phụ thuộc phần cứng bên dưới.\nECU Abstraction Layer gồm 4 nhóm:\nIO Hardware Abstraction: Trừu tượng hóa vị trí của các thiết bị ngoại vi I/O (on-chip hay on-board) và layout phần cứng ECU (kết nối pin vi điều khiển, mức tín hiệu…). Nhiệm vụ: biểu diễn tín hiệu I/O theo dạng điện (dòng, áp, tần số) và ẩn đi các thuộc tính layout phần cứng. Communication Hardware Abstraction: Trừu tượng hóa vị trí của các controller giao tiếp. Yêu cầu có một abstraction riêng cho mỗi hệ thống giao tiếp (LIN, CAN, FlexRay…). Nhiệm vụ: cung cấp cơ chế truy cập BUS channel đồng nhất bất kể controller nằm on-chip hay on-board. Memory Hardware Abstraction. Trừu tượng hóa vị trí các thiết bị bộ nhớ ngoại vi. Ví dụ: EEPROM on-chip và EEPROM ngoài đều được truy cập qua cùng một cơ chế (qua EEPROM Interface). On-Board Device Abstraction. Chứa các driver cho các thiết bị on-board của ECU không thuộc dạng cảm biến/cơ cấu chấp hành như external watchdogs… Truy cập các thiết bị này thông qua MCAL. 3.3. Services Layer. Đây là lớp cao nhất trong BSW, nằm ngay dưới RTE. Gồm ba nhóm dịch vụ chính:\nCommunication Services. Tập hợp các module phục vụ giao tiếp mạng xe: CAN, LIN, FlexRay, Ethernet\u0026hellip; Nhiệm vụ: Cung cấp Interface thống nhất đến mạng xe cho giao tiếp giữa các ứng dụng. Cung cấp dịch vụ quản lý mạng (Network Management) đồng nhất. Cung cấp Interface thống nhất cho giao tiếp chẩn đoán (Diagnostic Communication). Ẩn đi các thuộc tính giao thức và message khỏi ứng dụng. Memory Services. Quản lý việc đọc/ghi dữ liệu nonvolatile từ các memory driver khác nhau. NVRAM Manager cung cấp một RAM mirror làm giao diện dữ liệu cho ứng dụng để đọc nhanh. Nhiệm vụ: cung cấp dữ liệu nonvolatile đồng nhất, trừu tượng hóa vị trí và thuộc tính bộ nhớ, cùng các cơ chế quản lý (lưu, tải, checksum, lưu trữ đáng tin cậy…). System Services. Nhóm các module và hàm có thể dùng bởi tất cả các lớp trong BSW. Bao gồm: Real-time OS, Error Management, thư viện hàm (CRC, Interpolation…), ECU State Manager, Diagnostic Communication Manager… 3.4. Complex Device Drivers (CDD). CDD là thành phần đặc biệt được AUTOSAR cung cấp cho các tình huống mà ứng dụng cần truy cập phần cứng theo cách nhanh hơn – thường gặp với các tính năng yêu cầu thời gian thực (time-critical).\nLý do tồn tại của CDD:\nViệc truyền dữ liệu qua nhiều lớp BSW sẽ mất thêm thời gian – không phù hợp với các hệ thống cần phản hồi tức thì. Dùng để triển khai driver cho phần cứng chưa được AUTOSAR hỗ trợ. ","permalink":"https://embedded-lab.pages.dev/posts/bai-2-basic-software/","summary":"\u003ch2 id=\"1-tổng-quan-kiến-trúc-phân-lớp-autosar\"\u003e\u003cstrong\u003e1. Tổng Quan Kiến Trúc Phân Lớp AUTOSAR\u003c/strong\u003e.\u003c/h2\u003e\n\u003cp\u003eKiến trúc phân lớp (Layered Architecture) của AUTOSAR cung cấp toàn bộ cơ chế cần thiết để đạt được \u003cstrong\u003esự độc lập giữa phần mềm và phần cứng\u003c/strong\u003e. Toàn bộ phần mềm chạy trên vi điều khiển (microcontroller) được chia thành \u003cstrong\u003eba lớp chính\u003c/strong\u003e:\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/wp-content/uploads/2026/04/Autosar_Layer_Arch_1.png\"\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eASW\u003c/strong\u003e – Application Software Layer.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRTE\u003c/strong\u003e – Runtime Environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBSW\u003c/strong\u003e – Basic Software.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eÝ tưởng cốt lõi của kiến trúc này là \u003cstrong\u003etách biệt hoàn toàn\u003c/strong\u003e phần mềm ứng dụng (không phụ thuộc phần cứng) với phần mềm nền tảng (phụ thuộc phần cứng) thông qua tầng trung gian RTE.\u003c/p\u003e","title":"Bài 2: Kiến Trúc Phần Mềm AUTOSAR – Basic Software (BSW)."},{"content":"I. AUTOSAR là gì? AUTOSAR (viết tắt của AUTomotive Open System ARchitecture) là một chuẩn kiến trúc phần mềm mở cho ngành công nghiệp ô tô, được thành lập vào năm 2003.\nĐây là một kiến trúc phân lớp (layered architecture), được phát triển bởi sự hợp tác của các OEM (nhà sản xuất ô tô), nhà cung cấp (suppliers) và nhiều công ty trong các lĩnh vực phần mềm, bán dẫn và điện tử.\n💡 AUTOSAR là một chuẩn mở – nghĩa là tất cả tài liệu đặc tả đều được định nghĩa rõ ràng và có thể truy cập công khai từ website chính thức của tổ chức.\nII. ECU là gì? Trước khi đi sâu vào AUTOSAR, bạn cần hiểu khái niệm ECU (Electronic Control Unit) – đặc biệt nếu bạn mới bước vào ngành ô tô.\nNếu xem một chiếc xe như một hệ thống (system), bên trong xe chứa rất nhiều bộ điều khiển điện tử chịu trách nhiệm kiểm soát từng bộ phận riêng biệt. Ví dụ:\nECU động cơ (Engine Control Unit): kiểm soát hệ thống phun nhiên liệu, đánh lửa,… ECU hộp số: điều khiển hộp số tự động. ECU ABS: điều khiển hệ thống chống bó cứng phanh. ECU túi khí: kích hoạt túi khí trong tình huống va chạm III. Truy cập tài liệu chuẩn AUTOSAR. AUTOSAR là một chuẩn mở, vì vậy tất cả tài liệu đặc tả đều có thể tải về miễn phí từ website chính thức.\n3.1 Cách tải tài liệu:\nTruy cập website chính thức của AUTOSAR (autosar.org).\nVào mục Standards → Classic Platform.\nChọn phiên bản chuẩn – trong khóa học này chúng ta dùng AUTOSAR 4.4.0.\nTải về các file ZIP theo từng layer 3.2 Cấu trúc tài liệu trong mỗi layer: Khi giải nén file ZIP của bất kỳ layer nào (ví dụ: MCAL), bạn sẽ thấy 2 loại tài liệu:\nLoại tài liệu Tên đầy đủ Mục đích SRS Software Requirement Specification Tài liệu về yêu cầu của layer đó SWS Software Specification Tài liệu đặc tả kỹ thuật của layer đó Cách sử dụng: Dùng SWS để hiểu đặc tả kỹ thuật của từng layer. Dùng SRS khi cần làm rõ các yêu cầu cụ thể hơn.\nIV. Tổ chức AUTOSAR – Ai tạo nên chuẩn này? AUTOSAR không phải sản phẩm của một công ty đơn lẻ, mà là kết quả hợp tác của nhiều tổ chức. Các thành viên được chia thành 4 cấp bậc:\n4.1. Core Partners (Đối tác cốt lõi) Gồm 10 công ty (tại thời điểm viết bài) là sự kết hợp giữa OEM và nhà cung cấp lớn nhất. Có quyền kiểm soát tổ chức và nắm quyền quản lý cấp cao nhất. Là cơ quan quyết định về việc ban hành, phê duyệt và phát hành chuẩn AUTOSAR. Tham gia vào Leadership Working Group và đóng góp kỹ thuật cho chuẩn. 4.2. Premium Members (Thành viên cao cấp) Là các OEM hoặc nhà cung cấp hàng đầu sử dụng và đóng góp cho chuẩn AUTOSAR. Tham gia vào Leadership Working Group, có thể đóng góp kỹ thuật. Có quyền truy cập vào tài liệu làm việc nội bộ (working documents). 4.3. Development Members (Thành viên phát triển). Là các tổ chức nhỏ hơn hoặc startup muốn tham gia vào hệ sinh thái AUTOSAR. Chỉ được truy cập tài liệu chuẩn cuối cùng (không có working documents như Premium Members). Đôi khi vẫn có thể đóng góp kỹ thuật. 4.4. Attendees (Người theo dõi). Chủ yếu là tổ chức phi lợi nhuận hoặc cá nhân muốn theo dõi chuẩn. Chỉ được phép sử dụng tài liệu chuẩn, không tham gia đóng góp. V. Tại sao cần AUTOSAR? – Bài toán của ngành ô tô. 5.1. Lịch sử phát triển điện tử ô tô. Cuối thập niên 1980: Điện tử bắt đầu xuất hiện trong xe – điều khiển phun nhiên liệu, buồng đốt.\nNhững năm tiếp theo: Số lượng ECU tăng dần – ABS, hộp số tự động,…\nNăm 2005: Bùng nổ tính năng: túi khí, start-stop, tự động đỗ xe, cập nhật phần mềm OTA,…\nNăm 2021 đến nay: Xe kết nối (connected vehicle), ADAS, hệ thống tự lái\u0026hellip; và vẫn đang mở rộng\n5.2. Vấn đề với phần mềm không theo chuẩn AUTOSAR (None-Autosar).\nTrong mô hình phần mềm truyền thống (non-AUTOSAR), phần mềm ứng dụng được viết trực tiếp cho một phần cứng cụ thể (vi điều khiển). Điều này tạo ra sự gắn kết chặt chẽ (tight coupling) giữa phần cứng và phần mềm.\nHệ quả từ góc nhìn khách hàng (OEM):\nNếu cần thay đổi phần cứng hoặc vi điều khiển → phải phát triển lại toàn bộ phần mềm → chi phí rất lớn.\nHệ quả từ góc nhìn nhà cung cấp (Supplier):\nNhà cung cấp muốn bán một phần mềm cho nhiều khách hàng khác nhau → nhưng mỗi khách hàng dùng phần cứng khác nhau → không thể tái sử dụng dễ dàng.\nVI. AUTOSAR giải quyết bài toán như thế nào? AUTOSAR ra đời để tách biệt phần cứng và phần mềm thông qua kiến trúc phân lớp và trừu tượng hóa (abstraction). Nhờ đó, AUTOSAR mang lại các lợi ích sau:\nTăng tính linh hoạt trong phát triển phần mềm – nhờ cơ chế trừu tượng hóa, tách rời phần cứng và phần mềm. Tái sử dụng phần mềm – phần mềm phát triển một lần có thể dùng lại trên nhiều dòng xe hoặc chia sẻ giữa các khách hàng. Phát triển song song (parallel development) – các nhà cung cấp khác nhau có thể cùng phát triển đồng thời, giúp đưa sản phẩm ra thị trường nhanh hơn. Plug and Play phần mềm – khách hàng có thể chọn và tích hợp phần mềm tốt nhất từ nhiều nhà cung cấp khác nhau. Thúc đẩy đổi mới – chỉ giải pháp tốt nhất mới tồn tại được trên thị trường. ","permalink":"https://embedded-lab.pages.dev/posts/autosar-la-gi/","summary":"\u003ch2 id=\"i-autosar-là-gì\"\u003eI. AUTOSAR là gì?\u003c/h2\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/wp-content/uploads/2025/11/Autosar-Classic.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAUTOSAR\u003c/strong\u003e (viết tắt của \u003cstrong\u003eAUT\u003c/strong\u003eomotive \u003cstrong\u003eO\u003c/strong\u003epen \u003cstrong\u003eS\u003c/strong\u003eystem \u003cstrong\u003eAR\u003c/strong\u003echitecture) là một chuẩn kiến trúc phần mềm mở cho ngành công nghiệp ô tô, được thành lập vào năm \u003cstrong\u003e2003\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eĐây là một kiến trúc phân lớp (\u003cstrong\u003elayered architecture\u003c/strong\u003e), được phát triển bởi sự hợp tác của các \u003cstrong\u003eOEM\u003c/strong\u003e (nhà sản xuất ô tô), \u003cstrong\u003enhà cung cấp (suppliers)\u003c/strong\u003e và nhiều công ty trong các lĩnh vực phần mềm, bán dẫn và điện tử.\u003c/p\u003e","title":"Bài 1: Giới Thiệu về AUTOSAR."}]