AUTOSAR = KIẾN TRÚC HỆ THỐNG MỞ Ô TÔ

Trong bài trước, chúng ta đã văn học ra viễn cảnh về một thế giới đậm chất công nghệ. Khimà xe tự lái ra đời, cho phép hệ thống thông tin giải trí trên xe được nâng cấp lên mộttầm cao mới. Tuy vậy, cái gì xa vời quá thì nó thành viển vông.

Bạn đang xem: Autosar = kiến trúc hệ thống mở ô tô

Thế cho nên là giờ ta phải tổ lái nó về với hiện thực.

Rào cản ở đây là gì?

Để vượt rào thành công thì phải nhìn thấy rào đã. Thời điểm cách đây khoảng 6 năm, khi tôimới chuyển ngành sang automotive thì cảm giác đầu tiên là như thể vừa du hành về thời kỳ đồđá vậy. Tại sao làm phần mềm cho mấy cái hệ thống giải trí trên xe lại không thể sướng nhưlàm cho điện thoại?

Sau đó tôi nhận ra cái cục mình đang làm là để phục vụ cho lái xe, đối tượng phải chịu tráchnhiệm về an toàn của cái xe khi xe đang chạy. Về lý thuyết, cái gì càng phức tạp thì càng kéman toàn. Và hệ thống giải trí trên xe thì cũng vậy, đang lái xe thì mọi tương tác gây mất tậptrung đều bị cấm. Mà tốt nhất cái giao diện cũng càng xấu càng tốt, để lái xe họ chán dellthèm nhìn luôn ý thì hoàn hảo.

*
Đẹp quá nên chỉ là concept, General Motors / Buick

Vậy nên ta có những giới hạn về thiết kế. Nó không thể quá đẹp gây mất tập trung, cũng khôngđược quá phức tạp vì thế thì khỏi lấy chứng chỉ an toàn luôn. Mọi sáng tạo hầu như đi vào ngõcụt và các hãng xe thì chỉ còn nước ganh đua nhau về phần cứng kiểu chip khoẻ hơn, màn hìnhto hơn, nét hơn, trình chiếu AR hay công nghệ AI etc.

Thỉnh thoảng ta thấy những phát kiến kiểu như thế này.

*
Chặn biển quảng cáo bằng AR, WayRay

Mặc dù nó cũng sáng tạo, nhưng tôi cho rằng đây là minh chứng cho việc cạn kiệt ý tưởng, rảnhquá không có việc gì khác để làm mới phải nghĩ ra cái này (j/k). Trong khi chờ đợi xe tự hành,thứ có vẻ dài hạn thì ngay trong ngắn hạn ta vẫn cần một không gian để có thể triển khai dầncác ý tưởng về một hệ thống giải trí hiện đại. Vừa thêm được giá trị cho chiếc xe, lại vừa sẵnsàng cho tương lai.

Thành Rome không thể xây trong vòng một ngày.

Sẽ ít khả năng xe tự hành ra đời, và ngay ngày hôm sau hệ thống giải trí trên xe nghiễm nhiênđược lên đời từ cục đá sang thành iPhone. Sự tiến hoá là một quá trình tích luỹ, đòi hỏi sự chuẩnbị ngay từ hôm nay.

Hệ thống mạng trên xe

Chưa có một tiêu chuẩn chính xác nào cho việc định danh các thế hệ của thiết kế mạng trên xe,như tiêu chuẩn mạng viễn thông mà ta thường thấy (2G - 5G). Nên ở đây ta sẽ định danh nó mộtcách err… đại khái thế.

VN1 (vehicle network 1) - mạng cho xe thô sơ

Thời kỳ này thì chả có gì để nói vì xe cũng chưa phức tạp, như mạng điện trong nhà ý, vài cáicông tắc, vài con cảm biến, nối trực tiếp với nhau dạng Peer-to-Peer, và thông qua những giaothức đơn giản kiểu có điện hay không có điện etc.

VN2 - mạng broadcast với CAN, LIN etc.

Với số lượng ECU trở nên rất lớn trên xe và nhu cầu trao đổi dữ liệu phức tạp. Cách kết nốikiểu Peer-to-Peer là không hiệu quả, vì ta không thể cứ mỗi khi phát sinh nhu cầu truy cập dữliệu từ ECU nọ sang ECU kia thì lại kiếm một sợi dây để nối chúng lại với nhau. Những chuẩnkết nối dựa trên broadcast như CAN ra đời, dù có nhiều topology khác nhau nhưng bản chất chúnglà những mạng “ít dây”. Các ECU trao đổi dữ liệu kiểu cứ đẩy lên bus, tất cả những ECU kháctrong mạng đều nhận được và tự quyết định xem có phải cái mình cần không.

*
Mạng thế hệ thứ hai

Thiếu cục OBD, cục này cắm vào tất cả các mạng trên xe, vẽ vào rối.

Vì giới hạn tốc độ của giao thức cũng như thêm phần an toàn thì mạng trên xe sẽ được chia nhỏthành nhiều sub-network cho từng domain. Giữa các domain sẽ có một khối gọi là gateway, làmtrung gian để chia sẻ thông tin (message broker) và bảo vệ dữ liệu (firewall).

Với những domain có độ rủi ro cao do tiếp xúc với các nguồn không đảm bảo như Connectivity hayInfotainment, và thường cũng không real-time thì khối gateway sẽ được tách thành một ECU riêngchạy RTOS.

VN3 - mạng với Central Gateway

Có thể các bạn đã thấy ở VN2 là gateway của khối Connectivity khá đặc biệt khi nó kết nối vớitất cả các mạng khác trên xe. Thực ra hồi đầu khi chưa có cục Telematic, tức là xe chưa cóinternet thì thứ duy nhất giống kiểu vậy là cục OBD. Còn có cục Telematic vào thì hiểu đơn giảnlà nó kiểu OBD Over-The-Air.

Download, cài cắm firmware mới cho các ECU.Chuẩn đoán lỗi, thu thập thông tin đẩy lên cloud.Bật điều hoà bằng điện thoại khi chuẩn bị đi cho mát.Mất xe, tìm xe đi lạc, xoá dữ liệu nhạy cảm ⇨ AkaDayroi.

Chịu ảnh hưởng của IoT, người ta nhận thấy khối gateway này là nơi tuyệt vời để làm trung giantruyền nhận dữ liệu giữa tất cả các domain trên xe và nhận làm những task không tên, không biếtcho vào đâu như Analytic, hay ứng dụng mang tính kịch bản kiểu đỗ xe ngoài bãi, trời mưa thì tựkéo cửa kính lên chẳng hạn.

*
Mạng thế hệ thứ ba

Một số ECU chỉ sử dụng Ethernet, nhưng vẫn có đường CAN để wake-up.

Trong mạng VN3, về cơ bản các gateway riêng cho từng domain sẽ biến mất, thay vào đó là một cụcCentral Gateway cho tất cả các domain. Khối này cũng sẽ đảm nhận luôn nghiệp vụ của cục Telematictruyền thống. Tức là giờ đây khối Connectivity trở nên rất “dumb”.

Central Gateway cũng được thiết kế để chạy các ứng dụng cộng thêm, hiện thực hoá câu chuyện caras software platform. Với phần cứng vượt trội và được tính toán dư địa để mở rộng về sau, hệt nhưcách ta làm một cái điện thoại vậy. Phải khoẻ, phải thông minh và chạy ngon trong ít nhất là 3-5 năm.

Tuy nhiên, VN3 vẫn tồn tại nhược điểm ở chính tính tập trung. Nó tạo ra một điểm chết cho toàn hệthống (single point of failure). Tức là thằng Central Gateway này mà lăn ra chết thì thôi chết cảlũ. Vì vậy một thiết kế chấp nhận được sẽ nằm đâu đó giữa VN2 và VN3, để có các kênh dự phòng chotrường hợp Central Gateway dừng hoạt động, những tính năng an toàn cơ bản nhất vẫn chạy.

Hiện nay thì xe trên thị trường vẫn đang là VN2, VN3 thì được push nhiệt tình bởi Silicon Vendorsnên cũng sắp trình làng trong cỡ 1-2 năm nữa. Đến thời điểm đó ta có thể chứng kiến những chiếc xethực sự thông minh và giàu tính năng.

Phía nam biên giới

Cuộc đối thoại trong quán cafe:

- Cách đây đã lâu em đọc được về nó ở đâu đó, chắc là từ hồi em học cấp hai. Em không còn biết ởtrong cuốn sách nào nữa, chỉ nhớ chắc chắn đó là thứ bệnh mà nông dân làng F hay mắc phải. Anh cứtưởng tượng mình là một người nông dân và anh sống một mình trên thảo nguyên. Và ngày nào, ngày nàoanh cũng làm ruộng. Hoang mạc ngút tầm mắt. Không có gì, hoàn toàn không có gì ở xung quanh anh.Phía Bắc, đường chân trời, phía Nam, đường chân trời, phía Đông, đường chân trời, và phía Tây, vẫnlà đường chân trời. Chỉ thế thôi. Mỗi sáng, khi mặt trời hiện ra phía trên đường chân trời phía Đông,anh ra đồng làm việc, và khi mặt trời lên đến đỉnh, anh ngừng tay để ăn trưa. Khi mặt trời biến mấtsau đường chân trời phía Tây, anh về nhà đi ngủ.

- Anh nghĩ cuộc sống đó rất khác với ở công ty mà ai cũng biết là công ty nào đấy.

- Cái đó thì hẳn rồi, Ichini-san mỉm cười nói, rồi nàng hơi nghiêng đầu. Quả thật là rất khác. Vàngày nào cũng thế, cả năm.

- Nhưng vào mùa hè thì nóng lắm, không thể đi cày ở làng F được.

- Tất nhiên rồi, mùa hè thì anh đi onsite. Anh làm việc ở những nước mát mẻ; rồi, khi mùa thu tới,anh lại về làng F làm. Anh sống một cuộc sống như thế đấy. Anh cứ tưởng tượng anh là một nông dân ởlàng F đi.

- Xong rồi, em kể tiếp đi.

- Một ngày đẹp trời, trong sâu thẳm con người anh có cái gì đó chết đi.

- Chết? Cái gì chết?

Ichini-san lắc đầu.

- Em không biết. Cái gì đó. Cái gì đó gãy đi trong người anh và chết, khi mà suốt đời anh cứ nhìnmặt trời hiện ra phía trên đường chân trời phía Đông, hoàn thành cái vòng cung di chuyển của nó vàđi ngủ sau đường chân trời phía Tây. Khi đó anh sẽ vứt bàn phím xuống đất, và không nghĩ ngợi gì nữa,anh đi thẳng về phía Tây. Về phía Tây mặt trời. Và anh cứ đi như thế hàng ngày trời không ăn khônguống, như thể bị bỏ bùa, và cuối cùng anh gục xuống đất và chết. Chứng Hysteria F-ville là như thế đó.

- Nhưng ở phía Tây mặt trời có gì? Tôi hỏi.

- Cái đó thì em chịu. Có thể là không có gì. Có thể là có cái gì đó. Dù sao thì cũng rất khác vớiphía Nam biên giới.

- Thế ở phía Nam biên giới có gì?

- Phía Nam biên giới là Mexico anh ạ.

Thôi vứt mẹ Mexico của em đi, đã dốt không làm được thì bảo luôn lại còn bày đặt văn học. Phía Nambiên giới là cục MCU Gateway, đi xa hơn nữa ta gặp CAN bus và lấy được data em cần nhé. Thế rồi nànglăn ra khóc lóc thảm thiết, nhưng mà anh ơi em không biết lập trình MCU, lại cũng không biết đọc CANspec, ngày mai release rồi em biết phải làm sao, huhu.

SEAMLESS architecture

Điều mà tôi rất không thích về kiến trúc của xe hiện nay là nó phân định rạch ròi thành nhiều domain,trong mỗi domain lại chia làm nhiều ECU khiến cho việc khai thác dữ liệu trở nên rất khó khăn. Nhất làkhi bạn đứng ở góc độ một người lập trình ứng dụng thông thường, với hiểu biết hạn chế trong một vàiloại ECU.

Xem thêm: Làm Sao Biết Main Hỗ Trợ Sata 3, Làm Sao Biết Laptop Có Hỗ Trợ Sata Iii

Trong khi đó, tầm nhìn của chúng ta trong trung và dài hạn lại là car as software platform. Tức làai cũng có thể viết phầm mềm cho xe, như lập trình điện thoại bây giờ, chứ không giới hạn ở một nhómcác công ty lớn. Tức là 2 cái trên đang mâu thuẫn với nhau.

Companion app hell

Đội làm xe hay có cái phong cách thiết kế rất lởm là companion app. Giả dụ ta đang làm một cáiứng dụng dẫn đường trên Cluster, mà lại cần lấy thông tin chỉ dẫn kiểu rẽ trái, rẽ phải, đi thẳng 100mtừ Head Unit. Vậy thì chia buồn, nó là 2 cục khác nhau, và ta phải tạo ra thêm một cái ứng dụng nữatrên Head Unit để làm mỗi một trò rất ngu si là lấy dữ liệu để vứt cho cái ứng dụng trên Cluster.

Thôi, ngu tý cũng được, khổ cái là nó chưa dừng lại ở đấy. Hôm sau lại có một thằng nữa là thằng tựhành, thằng này cũng có nhu cầu lấy chỉ dẫn lộ trình để biết đường mà lái. Thế là cháu nó cũng làmngay một cái ứng dụng nữa trên con Head Unit, tất nhiên là cộng thêm một số loại dữ liệu khác để takhông thể dùng cái “cluster companion app” kia được. Đến đây hoặc là ta sửa lại cái ứng dụng trên HeadUnit và đổi tên nó thành “cluster and autonomous driving companion app”. Hoặc là ta cứ thêm cái nữacho vui thôi. Cách thiết kế này được gọi là thiết kế hướng kiểu như l*z thưa các bạn.

*

Mà thôi, từ giờ không gọi nó là companion app nữa, mà phải gọi là backdoor app, vì nó có nghiệp vụvẹo gì đâu mà bày đặt companion. Thiết kế kiểu trên sẽ tạo ra rất nhiều backdoor trên xe. Quan trọngnhất là không phải ai cũng đủ hiểu về hệ thống xe để đi viết backdoor, hoặc cứ cho là ta pro ta viếtđược đi thì ta cũng rất có thể không được phép vì cái cục đấy là close source.

Tất nhiên cũng có trường hợp ta cần companion app thật, có nghiệp vụ đàng hoàng chứ không đơn thuầnchỉ là expose một cái gì đó ra. Giả dụ ta làm một cái ứng dụng vừa vẽ lên Head Unit lại vừa vẽ lên đượcCluster, xong trên mỗi cục lại tính toán cái gì đấy. Thì nó lại còn lởm hơn nữa thưa quý ông, về cơ bảnta có hai cái ứng dụng phân tán với giao tiếp chồng chéo qua lại lẫn nhau.

Trong khi lẽ ra ta chỉ cần 1 ứng dụng duy nhất.

Heterogeneous app framework

SEAMLESS là kiến trúc được tạo ra để nhằm giải quyết bài toán trên. Nhìn xa hơn chút thì hệ thống thôngtin giải trí trên xe dần dần sẽ gồm rất nhiều “cục” khác nhau chứ không đơn thuần là mỗi Head Unit vớiCluster nữa. Khi mà càng nhiều unit được thêm vào, và nhu cầu tương tác giữa chúng càng lớn, thì ranhgiới giữa chúng lại càng được xoá nhoà. Cuối cùng, ta không thể cứ mãi nhìn vào từng cục và bảo ta cầnmột cái ứng dụng ở đây, một cái ứng dụng ở kia nữa. Cái ta nhìn thấy cuối cùng là một hệ thống, một hệthống SEAMLESS.

SEAMLESS hiểu đơn giản là no-boundary.

Đứng từ góc độ một người lập trình ứng dụng thông thường, ta nhìn thấy đây là cái xe, hết. Sẽ không cònnhững câu hỏi baby kiểu “phía Nam biên giới là cái gì”. Một heterogeneous app sẽ bao gồm nhiều component.Component khác nhau có thể chạy trên các ECU khác nhau tuỳ vào nhu cầu. Việc cài cắm, update và đảm bảotính tương thích giữa các version của những component hợp thành app được thực hiện tự động. Vấn đề chiasẻ dữ liệu thì được giải quyết bằng thiết kế micro service, cung cấp API thông qua heterogeneous binder.Các tay mơ nếu có nhu cầu lấy thông tin gì thì chỉ cần có 2 thứ, đầu tiên là API, và thứ hai là quyền sửdụng API đó. Chả cần quan tâm đến MCU hay CAN bus gì hết.

Heterogeneous binder

Về binder thì có 2 bài toán thôi.

Chọn giao thức truyền dẫn hiệu quả.Đảm bảo security cho API với permission.

Nói về security, ta cần định danh được ứng dụng đang gọi API là thằng nào, đã được grant những permissiongì. Thông tin này không thể tự ứng dụng đưa cho API được để tránh giả mạo. Với những OS truyền thống nhưAndroid hay iOS thì điều này khá đơn giản, quyền của ứng dụng là read-only, được nhúng vào ROM và đưa choservice thông qua kernel. Với hệ thống SEAMLESS thì câu chuyện phức tạp hơn một chút vì ta có rất nhiềuECU chạy những OS khác nhau. Việc đảm bảo định danh chính xác một ứng dụng chạy trên ECU nọ trong khi nógọi một service ở ECU kia cần một cơ chế vượt trên mức OS.

Phương án 1, dùng proxy

*

Phương án này là gần nhất với hướng tiếp cận của binder trên Android. Ta dựng một con firewall giữa ECUvà gateway. Con đường duy nhất để đi ra ngoài của các ứng dụng trên ECU là chạy qua một cục proxy, đượccài đặt trên cùng OS nên có thể dùng những cơ chế của OS để định danh ứng dụng mà không thể giả mạo.

Lưu ý là “firewall” ở đây có tính minh hoạ, giao thức giữa ECU và gateway có thể không phải Ethernet, vàECU cũng có thể quá dumb nên không có firewall. Mấu chốt ở đây là kết nối giữa ECU và gateway phải đượcgiới hạn để chỉ còn đường đi qua proxy. Nếu kết nối đó là serial thì đơn giản là cấp quyền sao cho duy nhấtcái proxy được dùng thôi chẳng hạn.

Ưu điểm:

Mì ăn liền, dễ hiểu, dễ implement.

Nhược điểm:

OS không có cơ chế để proxy định danh app thì chịu.Data buộc phải route hết qua proxy ⇨ nặng.Tuỳ trường hợp, thường data ko lớn.

Phương án 2, dựa trên authentication

*

Ta đặt permissions database trên gateway, khi ứng dụng kết nối với gateway thì sẽ phải authenticate, haynói nôm na là đăng nhập để gateway định danh. Cách này khá giống với những web server truyền thống, nóichung là chả biết anh từ đâu chui ra, con ông nọ, cháu bà kia gì đấy không quan tâm, muốn dùng dịch vụthì mời anh show token ra.

Ưu điểm:

Portable, không cần OS hỗ trợ.Permissions được lưu tập trung ở gateway.Dễ update, revoke, grant thêm quyền nếu cần.Attack surface nhỏ hơn nên có vẻ an toàn hơn tý.

Nhược điểm:

Single point of failure.Yêu cầu phải là mạng VN3.

Phương án 3, các biến thể khác

Tuỳ vào các ràng buộc khác nhau mà hệ thống có thể kết hợp cả phương án (1) lẫn phương án (2), vì thựcra chúng nó cũng không phải loại trừ lẫn nhau. Ngoài ra thì cũng có nhiều biến thể khác cho phù hợp vớithực tế, ví dụ như thay vì data route qua proxy thì ta có thể cho phép gateway pull permissions databasetừ trusted process trên ECU chẳng hạn. Miễn sao API đưa ra cho người lập trình ứng dụng vẫn đồng nhất.Tức là từ góc độ của họ thì bên dưới cơ chế security vận hành thế nào họ không cần quan tâm.

Đừng có tự dưng đổi mẹ cái API đi là được.

Sao không dùng AUTOSAR?

Tôi có nhận được câu hỏi rất hay là AUTOSAR có VFB, vậy sao ta không dùng?

Giải ngố về VFB

Do bài viết có hướng đến cả hạng “gà” về lập trình ô tô, nên ở đây xin phép được nói qua một chút về VFBđể tiện theo dõi. Một trong những nguyên tắc của thằng AUTOSAR là cho phép các component có thể được deploy /relocate thoải mái lên các ECU khác nhau.

*
AUTOSAR Virtual Function Bus, Nico Naumann

Đứng ở góc độ người lập trình component, cái ta quan tâm là chức năng và giao tiếp giữa các component ở mứclogic. Do đó, với mỗi component ta sẽ định nghĩa các cổng giao tiếp, rồi nối chúng lại với nhau bằng cái gọilà virtual function bus. Bus này là ảo và chỉ tồn tại trong quá trình design. Khi deploy lên hệ thống thậtthì AUTOSAR sẽ thay thế những đặc tả ở mức VFB bằng các kết nối thực sự, là cái cục RTE, cục này được generatetự động dựa trên file cấu hình.

Nếu câu hỏi là VFB có hay ho không, thì khẳng định luôn là hay, từ cách thiết kế để người lập trình componentkhông cần quan tâm đến CAN, LIN etc. cho đến khả năng relocate component sang ECU khác đều rất hay. SEAMLESScũng chia sẻ nhiều phương châm thiết kế với AUTOSAR ở khoản này.

Tuy nhiên SEAMLESS không phải được tạo ra nhằm kill AUTOSAR.

Hạn chế của AUTOSAR

AUTOSAR có nhiều vấn đề khi câu chuyện car as software platform xuất hiện.

Các ECU chạy AUTOSAR hầu hết có phần cứng hạn chế, và chịu nhiều ràng buộc chặt chẽ về safety, latency etc.Vì vậy quá trình resolve từ VFB sang RTE được thực hiện offline. Một khi đã có RTE thì err… nó là code C.Code này được compile thành ứng dụng và không thể thay đổi trừ khi ta rebuild và flash lại con ECU.

Với SEAMLESS, mục tiêu của ta là car as software platform. Các component của SEAMLESS được thiết kế theohướng microservice, nó sẽ gần với lập trình ứng dụng hiện đại trên web / mobile hơn là embedded. SEAMLESScomponent được deploy chủ yếu trên các domain như Telematic, ADAS, Autonomous Driving và Infotainment etc.Với life-cycle phức tạp. Một số microservice không quan trọng có thể bị kill khi thiếu tài nguyên, tuỳ vàođộ ưu tiên và policy của hệ thống.

Thậm chí một microservice có thể được migrate online từ cục đang có tải CPU cao sang cục khác đỡ bận rộnhơn. Nên không thể fix cứng giao thức và địa chỉ của chúng từ khi compile như thằng AUTOSAR được. SEAMLESSgateway sẽ đứng ra điều phối và resolve ra “config” in runtime.

AUTOSAR cũng thiết kế với mindset “tin nhau là chính”, nên trong câu chuyện VFB không có vấn đề security.Đây thực ra cũng là câu chuyện của mấy cái mạng broadcast chuyên cho ô tô như CAN vs LIN etc. Một khi đượcchạm vào bus thì ra thích đọc gì, gửi gì đi là tuỳ tâm. SEAMLESS thì API có permission, không được grantquyền thì khỏi dùng API.

Ngoài ra thì còn một số lý do khác, ví dụ như dùng AUTOSAR thì phải chơi kiểu AUTOSAR, thằng này nó forcekhá chặt và dựa nhiều vào tool khiến cho việc sử dụng những stack khác, ví dụ như Node chẳng hạn là khôngkhả thi. Chưa thấy thằng AUTOSAR nào hỗ trợ Javascript, hội developer mì ăn liền không thích điều này. Vìứng dụng ở cái thời đại đó có khi chỉ đơn giản là một đoạn script kiểu trời mưa lúc xe đang đỗ ngoài trờithì kéo cái cửa kính lên chẳng hạn. Những ứng dụng kiểu này có thể được download về và chạy luôn, trong khivới AUTOSAR ta phải rebuild và reflash cái gì đấy, mỗi loại xe một cục binary khác nhau nhé :)

SEAMLESS conflict với AUTOSAR?

Tôi cũng nhận được một câu hỏi khác đại ý CAN là broadcast, thằng nhận tự quyết định xem có liên quan gìđến nó không. Trong khi SEAMLESS proxy lại có nhiệm vụ routing data đến đúng thằng đang cần. Ngoài ra thìCAN làm gì có permission? Câu này nói chung không hỏi về AUTOSAR nhưng thôi trả lời luôn vào đây cho cùngcontext. CAN vs LIN gì đó là việc của thằng AUTOSAR, những domain mà đội lập trình ứng dụng bình thườngkhông quan tâm, và cũng không phải scope của SEAMLESS. Central Gateway nó là gateway, không phải switch.Nó có nhiệm vụ phân tích cái đống tín hiệu CAN, LIN, BLE etc. và cung cấp API dưới dạng thông tin.

Vận tốc xe, góc lái, đèn xi nhan là thông tin.Còn CAN frame thì dek phải thông tin.

Mấy thằng như CAN, LIN etc. không phải API trong context của SEAMLESS.

Adaptive AUTOSAR?

Theo trend tự hành với car as software platform thì AUTOSAR cũng có một món vũ khí mới là thằng AdaptiveAUTOSAR. Hướng đến fast ECU ở các SEAMLESS domain. Hiện nay tôi cũng chưa nắm được nhiều thông tin về nó,nhưng tìm hiểu sơ thì thấy khá ổn. Với bề dày của tổ chức AUTOSAR thì khả năng Adaptive AUTOSAR trở thànhchuẩn thống trị là rất cao. Anh em mà có nghiên cứu về SEAMLESS thì nên tính tới nó trong bức tranh của mình.

Fun Facts

Bài viết có đạo tý văn của Murakami

Đã cảm ơn và tín dụng bằng cách mua sách, không đọc chùa nhé.

SEAMLESS là một dòng dự án

Ngoài việc được đặt cho tên kiến trúc heterogeneous app, nó còn được dùng làm tên dự án Cockpit thế hệmới ở công ty F. Lúc đầu vì uống nhiều thuốc của các anh Silicon Vendors quá nên định đặt là hyperapplication framework. Nhưng sau nhận ra là mặc dù hypervisor là platform tuyệt vời để làm mấy trò này,nhưng thực tế nó không couple vào hypervisor. Tức là ta vẫn có thể làm heterogeneous app mà không cầnđến hypervisor nên thôi đổi tên cho đỡ hiểu nhầm.