用于微控制器MCU的面向服务架构、电子电器架构的制作方法

用于微控制器mcu的面向服务架构、电子电器架构
技术领域
1.本发明涉及车辆总线通信技术领域，具体涉及一种用于微控制器mcu的面向服务架构、电子电器架构。


背景技术：

2.目前随着高速车载千兆以太网已被纳入汽车主干网络，汽车的电子电器架构(electrical/electronic architecture, eea)正经历着由传统分布式电子控制单元（electronic control unit, ecu)架构向“中央计算平台+域控制器”架构转变。
3.智能化交互，场景化的车控体验，多域能力融合，软硬件解藕以及灵活的软件部署及更新等要求汽车各个域软件采用面向服务架构(service-oriented architecture, soa)，以服务的形式将能力提供出来。智能车控控制器，智能座舱控制器和智能驾驶控制器由于采用运算处理能力强大的微处理器(micro processor unit, mpu)，其可以基于成熟的数据分发服务(data distribution service, dds)，基于因特网协议的可扩展面向服务通信中间件(scalable service-oriented middleware over ip, some/ip)及快速数据总线(fast dbus, fdbus)等远程过程调用(remote procedure call, rpc)框架实现soa框架。
4.但是采用微控制器(micro controller unit, mcu) 的域控制器由于资源及处理能力的限制，并没有成熟可靠、对应用(application, app)开发友好、可扩展的soa框架，这对ecu功能集中以及域控制器功能服务化造成障碍，限制了整车服务能力的释放，增加了智能座舱及智能驾驶app能力拓展和体验提升的难度。
5.相应地，本领域需要一种新的用于微控制器mcu的面向服务架构方案来解决上述问题。


技术实现要素：

6.为了克服上述缺陷，提出了本发明，以提供解决或至少部分地解决在“中央计算平台+域控制器”的电子电器架构下实现整车soa框架的统一性的技术问题。
7.在第一方面，提供一种用于微控制器mcu的面向服务架构，基于所述面向服务架构实现服务端和客户端的网络通信，所述面向服务架构包括接口定义语言层、代码生成工具层、面向服务通信模型层和面向服务架构总线管理层；所述接口定义语言层被配置成定义面向服务架构通信数据和面向服务架构通信接口；所述代码生成工具层被配置成基于所述接口定义语言层定义的所述面向服务架构通信数据生成所述面向服务架构通信数据的目标代码、以及基于所述面向服务架构通信接口和所述面向服务通信模型层提供的通信模型分别生成所述服务端和所述客户端的所述面向服务架构通信接口代码；所述面向服务通信模型层被配置成提供所述通信模型；
所述面向服务架构总线管理层被配置成对所述面向服务架构通信数据进行处理以及对所述服务端和所述客户端的通信进行管理。
8.在上述用于微控制器mcu的面向服务架构的一个技术方案中，所述接口定义语言层被配置成使得所述服务端基于开源的protobuf数据序列化协议定义所述面向服务架构通信接口和所述面向服务架构通信数据；和/或，所述代码生成工具层至少包括代码模板、编译器和解析器，所述代码生成工具层被配置成基于所述编译器生成所述接口定义语言层定义的所述面向服务架构通信数据的目标代码，以及被配置成使得所述服务端和所述客户端分别基于所述解析器解析的所述面向服务架构通信接口，并分别基于所述服务端和所述客户端解析的所述面向服务架构通信接口、所述面向服务通信模型层提供的所述通信模型以及所述代码模板分别生成所述服务端和所述客户端的所述面向服务架构通信接口代码；和/或，所述面向服务通信模型层被配置成提供所述通信模型，其中所述通信模型包括请求/应答模型、发后即忘模型、通知事件模型和现场通信模型；和/或，所述面向服务架构总线管理层被配置包括：面向服务架构服务权限管理模块、面向服务架构服务端/客户端连接管理模块、socket通信连接管理模块、socket通信协议配置模块、socket通信数据包封装模块和socket通信数据包解析模块。
9.在第二方面，提供一种基于上述用于微控制器mcu的面向服务架构的通信方法，用于服务端和客户端的信息通信，所述方法包括：所述服务端基于所述接口定义语言层的protobuf数据序列化协议定义面向服务架构通信数据和面向服务架构通信接口；所述服务端和所述客户端基于所述代码生成工具层中的编译器生成所述面向服务架构通信数据的目标代码；所述服务端和所述客户端基于所述代码生成工具层中的解析器解析所述面向服务架构通信接口，并基于所述面向服务通信模型以及所述代码生成工具层中的代码模板分别生成所述服务端和所述客户端的所述面向服务架构通信接口代码；所述服务端与所述客户端基于生成的所述服务端和所述客户端的所述面向服务架构通信接口代码进行通信。
10.在第三方面，提供一种车辆电子电器架构，所述架构包括中央计算平台、至少一个域控制器以及总线；所述中央计算平台被配置成包括至少一个基于微处理器mpu的智能控制器；所述域控制器被配制成以微控制器mcu作为主控芯片，所述微控制器mcu被配置为采用上述用于微控制器mcu的面向服务架构；所述总线被配置成连接所述智能控制器与所述域控制器的面向服务架构总线。
11.在上述车辆电子电器架构的一个技术方案中，每个所述域控制器包括至少一个域控制器服务端、至少一个域控制器客户端和所述微控制器mcu面向服务架构，所述域控制器服务端通过所述微控制器mcu面向服务架构发布提供的服务，所述域控制器客户端通过所
述微控制器mcu面向服务架构请求服务。
12.在上述车辆电子电器架构的一个技术方案中，所述中央计算平台包括智能座舱控制器、智能车载控制器以及智能驾驶控制器中至少一个，且所述智能座舱控制器、智能车载控制器和智能驾驶控制器之间使用以太网通信。
13.在上述车辆电子电器架构的一个技术方案中，所述中央计算平台包括至少一个第一微处理器mpu智能控制器，所述第一微处理器mpu智能控制器包括至少一个第一智能控制器服务端、至少一个第一智能控制器客户端和所述微控制器mcu面向服务架构，所述智能控制器客户端基于所述微控制器mcu面向服务架构总线请求所述域控制器上的服务。
14.在上述车辆电子电器架构的一个技术方案中，所述中央计算平台还包括至少一个第二微处理器mpu智能控制器和微处理器mpu总线；所述第一微处理器mpu智能控制器和第二微处理器mpu智能控制器之间通过所述微处理器mpu总线通信连接；所述第一微处理器mpu智能控制器还包括微处理器mpu面向服务架构；所述第二微处理器mpu智能控制器包括至少一个所述智能控制器服务端、至少一个所述智能控制器客户端和所述微处理器mpu面向服务架构，所述第二微处理器mpu智能控制器的所述智能控制器客户端通过所述微处理器mpu智能控制器请求所述域控制器上的服务。
15.在上述车辆电子电器架构的一个技术方案中，所述域控制器与所述中央计算平台之间通过车载以太网通信和/或can通信；和/或，当所述电子电器架构包括多个所述域控制器时，多个所述域控制器之间通过所述车载以太网通信。
16.在第四方面，提供一种驾驶设备，所述驾驶设备包括驾驶设备本体和上述车辆电子电器架构的技术方案中任一项技术方案所述的车辆电子电器架构。
17.在第五方面，提供一种电子设备，该电子机设备包括处理器和存储装置，所述存储装置适于存储多条程序代码，所述程序代码适于由所述处理器加载并运行以执行上述面向服务架构的通信方法的技术方案中所述的面向服务架构的通信方法。
18.在第六方面，提供一种计算机可读存储介质，该计算机可读存储介质其中存储有多条程序代码，所述程序代码适于由处理器加载并运行以执行上述面向服务架构的通信方法的技术方案所述的面向服务架构的通信方法。
19.本发明上述一个或多个技术方案，至少具有如下一种或多种有益效果：在实施本发明的技术方案中，在微控制器mcu上部署面向服务架构，基于面向服务架构实现服务端和客户端的网络通信，面向服务架构由接口定义语言层、代码生成工具、面向服务通信模型层和面向服务架构总线管理层组成，接口定义语言层被配置成面向服务架构通信数据和面向服务架构通信接口；代码生成工具层被配置成生成面向服务架构通信数据的目标代码以及服务端和客户端的面向服务架构通信接口代码；面向服务通信模型层被配置成提供面向服务架构支持的通信模型；面向服务架构总线管理层被配置成对面向服务架构通信数据进行处理以及对服务端和客户端的通信进行管理。通过上述实施方式，提供了可应用于微控制器mcu的面向服务架构，基于该面向服务架构能够实现微控制器mcu客户端和服务端的数据通信。
20.进一步地，将该应用于微控制器mcu的soa框架应用于“中央计算平台+域控制器”的电子电器架构，该中央计算平台至少包括一个基于微处理器mpu的智能控制器；域控制器被配制成以微控制器mcu作为主控芯片，该微控制器mcu采用上述用于微控制器mcu的面向
服务架构；且在面向服务架构的域控制器之间、域控制器与智能控制器之间各建立一条面向服务架构通信总线，可以实现域控制器之间的面向服务架构通信，进而实现整车面向服务架构的统一。
21.进一步地，通过将应用于微控制器mcu的面向服务架构框架部署在中央计算平台的任一个智能控制器上，对于该中央计算平台中没有部署该微控制器mcu的soa框架的其他智能控制器，可以经由部署了微处理器mpu的智能控制器实现与域控制器的面向服务架构通信，从而降低了域控制器应用的开发复杂度，使传统分散在各个ecu上的功能得以在域控制器上以服务的形式对外提供出去，可满足域控制器之间，域控制器与智能座舱控制器，智能驾驶控制器之间的面向服务架构通信，保证了整车面向服务架构的统一，为创建全车智能化场景服务奠定基础。
附图说明
22.参照附图，本发明的公开内容将变得更易理解。本领域技术人员容易理解的是：这些附图仅仅用于说明的目的，而并非意在对本发明的保护范围组成限制。其中：图1是根据本发明的一个实施例的用于微控制器mcu的面向服务架构的主要结构框图；图2是根据本发明的一个实施例的用于微控制器mcu的面向服务架构的通信协议传输格式；图3是根据本发明的一个实施例的用于微控制器mcu的面向服务架构的通信模型示意图；图4是根据本发明的另一个实施例的用于微控制器mcu的面向服务架构的通信模型示意图；图5是根据本发明的另一个实施例的用于微控制器mcu的面向服务架构的通信模型示意图；图6是根据本发明的另一个实施例的用于微控制器mcu的面向服务架构的通信模型示意图；图7是根据本发明的一个实施例的面向服务架构的通信方法的主要步骤流程示意图；图8是根据本发明的一个实施例的车辆电子电器架构的主要结构框图；图9是根据本发明的一个实施例的中央计算平台的主要结构框图；图10是根据本发明一个实施例的一种面向服务架构的通信设备。
具体实施方式
23.下面参照附图来描述本发明的一些实施方式。本领域技术人员应当理解的是，这些实施方式仅仅用于解释本发明的技术原理，并非旨在限制本发明的保护范围。
24.在本发明的描述中，“模块”、“处理器”可以包括硬件、软件或者两者的组合。一个模块可以包括硬件电路，各种合适的感应器，通信端口，存储器，也可以包括软件部分，比如程序代码，也可以是软件和硬件的组合。处理器可以是中央处理器、微处理器、图像处理器、数字信号处理器或者其他任何合适的处理器。处理器具有数据和/或信号处理功能。处理器
可以以软件方式实现、硬件方式实现或者二者结合方式实现。非暂时性的计算机可读存储介质包括任何合适的可存储程序代码的介质，比如磁碟、硬盘、光碟、闪存、只读存储器、随机存取存储器等等。术语“a和/或b”表示所有可能的a与b的组合，比如只是a、只是b或者a和b。术语“至少一个a或b”或者“a和b中的至少一个”含义与“a和/或b”类似，可以包括只是a、只是b或者a和b。单数形式的术语“一个”、“这个”也可以包含复数形式。
25.目前，用于mcu的soa由于资源及处理能力的限制，没有成熟可靠、对app开发友好、可扩展的soa。本发明通过提供了一种用于mcu的soa，实现了soa服务端和客户端的网络通信，实现了一种可落地的基于mcu域控制器的soa框架。
26.参阅附图1，图1是根据本发明的一个实施例的用于微控制器mcu的面向服务架构的主要结构框图。如图1所示，本发明实施例中的soa包括接口定义语言层101、代码生成工具层102、面向服务通信模型层103和面向服务架构总线管理层104。
27.接口定义语言层101被配置成定义soa通信数据和soa通信接口。
28.代码生成工具层102被配置成基于接口定义语言层101定义的soa通信数据生成soa通信数据的目标代码、以及基于soa信接口和面向服务通信模型层103提供的通信模型分别生成服务端和客户端的soa通信接口代码。
29.面向服务通信模型层被配置成提供soa通信模型。
30.面向服务架构总线管理层被配置成对soa通信数据进行处理以及对服务端和客户端的通信进行管理。
31.通过上述实施方式，实现了一种可落地的基于mcu域控制器的soa框架，实现了soa服务端和客户端的网络通信，使之成为整车soa的重要组成部分。
32.下面对上述用于mcu的soa主要结构作进一步说明。
33.在一些实施方式中，接口定义语言层101被配置成使得服务端基于开源的protobuf数据序列化协议定义soa通信接口和soa通信数据。
34.具体地，服务端使用google开源的protobuf作为接口定义语言，protobuf支持语法扩展；服务端定义的接口定义语言包括两部分，第一部分为如下所示的protobuf扩展语法文件：syntax = "proto3";import "google/protobuf/descriptor.proto";enum methodtype{
ꢀꢀꢀꢀ
request_reply
ꢀꢀꢀꢀꢀꢀ
= 0;
ꢀꢀꢀꢀ
fire_forget
ꢀꢀꢀꢀꢀꢀꢀꢀ
= 1;
ꢀꢀꢀꢀ
event
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
= 2;
ꢀꢀꢀꢀ
field_with_get
ꢀꢀꢀꢀꢀ
= 3;
ꢀꢀꢀꢀ
field_with_set
ꢀꢀꢀꢀꢀ
= 4;
ꢀꢀꢀꢀ
field_with_get_set = 5;}message null{
}extend google.protobuf.methodoptions{
ꢀꢀꢀꢀ
int32 msg_id = 9001;
ꢀꢀꢀꢀ
methodtype method_type = 90010;}第二部分为如下所示的基于protobuf原生语法和第一部分的扩招语法的服务定义文件：syntax = "proto3";import "soa_option.proto";package example;// request messagemessage request_msg {
ꢀꢀꢀꢀ
int32 req_a = 1;
ꢀꢀꢀꢀ
int32 req_b = 2;}// reply messagemessage reply_msg {
ꢀꢀꢀꢀ
int32 rep_a = 1;}// fire&forget messagemessage fire_msg {
ꢀꢀꢀꢀ
int32 fire_a = 1;
ꢀꢀꢀꢀ
int32 fire_b = 2;}// event messagemessage event_msg {
ꢀꢀꢀꢀ
int32 evt_a = 1;
ꢀꢀꢀꢀ
double evt_b = 2;}// field message amessage field_msg_a {
ꢀꢀꢀꢀ
int32 fld_aa = 1;
ꢀꢀꢀꢀ
int32 fld_ab = 2;}// field message bmessage field_msg_b {
ꢀꢀꢀꢀ
int32 fld_ba = 1;
ꢀꢀꢀꢀ
int32 fld_bb = 2;
}// field message cmessage field_msg_c {
ꢀꢀꢀꢀ
int32 fld_ca = 1;
ꢀꢀꢀꢀ
int32 fld_cb = 2;}service example {
ꢀꢀꢀꢀ
rpc method_rr(request_msg) returns (reply_msg) {
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (msg_id) = 1;
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (method_type) = request_reply;
ꢀꢀꢀꢀ
}
ꢀꢀꢀꢀ
rpc method_ff(fire_msg) returns (null) {
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (msg_id) = 2;
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (method_type) = fire_forget;
ꢀꢀꢀꢀ
}
ꢀꢀꢀꢀ
rpc method_evt(event_msg) returns (null) {
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (msg_id) = 3;
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (method_type) = event;
ꢀꢀꢀꢀ
}
ꢀꢀꢀꢀ
rpc method_filed_a(field_msg_a) returns (null) {
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (msg_id) = 4;
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (method_type) = field_with_get;
ꢀꢀꢀꢀ
}
ꢀꢀꢀꢀ
rpc method_filed_b(field_msg_b) returns (null) {
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (msg_id) = 5;
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (method_type) = field_with_set;
ꢀꢀꢀꢀ
}
ꢀꢀꢀꢀ
rpc method_filed_c(field_msg_c) returns (null) {
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (msg_id) = 6;
ꢀꢀꢀꢀꢀꢀꢀꢀ
option (method_type) = field_with_get_set;
ꢀꢀꢀꢀ
}}以上是protobuf扩展语法文件以及基于protobuf原生语法和第一部分的扩招语法的服务定义文件，文件内包含soa通信数据定义和soa通信接口定义。
35.在一些实施方式中，代码生成工具层102至少包括代码模板、编译器和解析器。
36.代码生成工具层102被配置成基于编译器生成接口定义语言层101定义的soa通信数据的目标代码，以及被配置成使得服务端和客户端分别基于解析器解析soa通信接口，并分别基于服务端和客户端解析的soa通信接口、面向服务通信模型层103提供的通信模型以及代码模板分别生成服务端和客户端的soa通信接口代码。
37.具体地，服务端和客户端首先使用code generator中的开源的protoc和nanopb生成soa通信数据的目标c代码，其中，soa通信数据的目标c代码如下所示：/* event message */typedef struct _example_event_msg {
ꢀꢀꢀꢀ
int32_t evt_a;
ꢀꢀꢀꢀ
double evt_b;} example_event_msg;/* field message a */typedef struct _example_field_msg_a {
ꢀꢀꢀꢀ
int32_t fld_aa;
ꢀꢀꢀꢀ
int32_t fld_ab;} example_field_msg_a;/* field message a */typedef struct _example_field_msg_b {
ꢀꢀꢀꢀ
int32_t fld_ba;
ꢀꢀꢀꢀ
int32_t fld_bb;} example_field_msg_b;/* field message a */typedef struct _example_field_msg_c {
ꢀꢀꢀꢀ
int32_t fld_ca;
ꢀꢀꢀꢀ
int32_t fld_cb;} example_field_msg_c;/* fire&forget message */typedef struct _example_fire_msg {
ꢀꢀꢀꢀ
int32_t fire_a;
ꢀꢀꢀꢀ
int32_t fire_b;} example_fire_msg;/* reply message */typedef struct _example_reply_msg {
ꢀꢀꢀꢀ
int32_t rep_a;} example_reply_msg;/* request message */typedef struct _example_request_msg {
ꢀꢀꢀꢀ
int32_t req_a;
ꢀꢀꢀꢀ
int32_t req_b;} example_request_msg;进一步地，服务端使用code generator中的python parser解析接口定义语言层101中的soa通信接口，并根据soa通信模型以及code template生成soa通信接口代码如下所示：
void example_demo_stub_method_rr_onrequest(const example_request_msg* const msg);void example_demo_stub_method_rr_reply(const example_reply_msg* const msg);void example_demo_stub_method_ff_onrequest(const example_fire_msg* const msg);void example_demo_stub_method_evt_publish(const example_request_msg* const msg);void example_demo_stub_method_field_a_publish(const example_field_msg_a* const msg);void example_demo_stub_method_field_a_onget();void example_demo_stub_method_field_put(const example_field_msg_a* const msg);void example_demo_stub_method_field_b_publish(const example_field_msg_b* const msg);void example_demo_stub_method_field_b_onset(const example_field_msg_b* const msg);void example_demo_stub_method_field_c_publish(const example_field_msg_c* const msg);void example_demo_stub_method_field_c_onget();void example_demo_stub_method_field_put(const example_field_msg_c* const msg);void example_demo_stub_method_field_c_onset(const example_field_msg_c* const msg);以上为服务端生成的soa通信接口代码。
38.客户端使用code generator中的python parser解析接口定义语言层101中的soa通信接口，并根据soa通信模型以及code template生成soa通信接口代码如下所示：void example_demo_proxy_method_rr_request(const example_request_msg* const msg);void example_demo_proxy_method_rr_onreply(const example_reply_msg* const msg);void example_demo_proxy_method_ff_request(const example_fire_msg* const msg);void example_demo_proxy_method_evt_onpublish(const example_event_msg* const msg);void example_demo_proxy_method_field_a_onpublish(const example_field_msg_a* const msg);void example_demo_proxy_method_field_a_get();void example_demo_proxy_method_field_a_onput(const example_field_msg_
a* const msg);void example_demo_proxy_method_field_b_onpublish(const example_field_msg_b* const msg);void example_demo_proxy_method_field_b_set(const example_field_msg_b* const msg);void example_demo_proxy_method_field_c_onpublish(const example_field_msg_c* const msg);void example_demo_proxy_method_field_c_get();void example_demo_proxy_method_field_a_onput(const example_field_msg_c* const msg);void example_demo_proxy_method_field_c_set(const example_field_msg_c* const msg);以上为客户端生成的soa通信接口代码。
39.在一些实施方式中，面向服务通信模型层103被配置成提供通信模型，其中，通信模型包括请求/应答request/reply模型、发后即忘fire&forget模型、通知事件notification event模型和现场通信field模型。
40.在本实施方式中，同一域控制器内部的服务端和客户端可以直接通过代码生成工具层102中生成的各自的soa通信接口代码与域控制器内部的soa进行通信，以使得服务端和客户端基于soa完成通信；不同域控制器之间的服务端和客户端也可以通信，服务端或客户端首先通过代码生成工具层102中生成的各自的soa通信接口代码与域控制器内部的soa进行通信，不同域控制器的soa可以通过面向服务架构总线管理层104中创建管理的socket进行通信，该socket上封装了私有通信协议，不同域控制器之间的服务端与客户端之间可以基于该socket上封装的的私有通信协议完成跨域通信。
41.其中，socket上封装的私有通信协议为构建于传输层之上的请求协议数据单元pdu，pud的传输格式如图2所示。
42.进一步的，在一些实施方式中，请求应答模型的通信流程如图3所示。在图3中，域控制器1中的客户端与域控制器2中的服务端基于请求应答模型完成通信。客户端通过soa向服务端请求服务，服务端应答后，通过soa提供服务给客户端。
43.其中，域控制器1中soa通过socket的请求pdu与域控制器2中soa通信，域控制器2中soa通过socket的应答pdu与域控制器1中soa通信。
44.在一些实施方式中，发后即忘模型的通信流程如图4所示。在图4中，域控制器1中的客户端与域控制器2中的服务端基于发后即忘模型完成通信。客户端通过soa向服务端发送服务请求即为完成通信。
45.其中，域控制器1中soa通过socket的发后即忘pdu与域控制器2中soa通信。
46.在一些实施方式中，通知事件模型的通信流程如图5所示。在图5中，域控制器1中的客户端与域控制器2中的服务端基于通知事件模型完成通信。服务端发布服务至soa供客户端订阅，客户端向soa订阅服务，若客户端订阅的为服务端已发布的服务，则订阅成功；若客户端订阅的为服务端未发布的服务，则订阅失败。
47.其中，域控制器2中soa通过socket的通知事件pdu与域控制器1中soa通信。
48.在一些实施方式中，现场通信模型的通信流程如图6所示。在图6中，域控制器1中的客户端与域控制器2中的服务端基于现场通信模型由上至下依次完成三种通信。第一种通信为服务端发布服务至soa供客户端订阅，客户端向soa订阅服务，若客户端订阅的为服务端已发布的服务，则订阅成功，若客户端订阅的为服务端未发布的服务，则订阅失败；第二种通信为客户端通过soa向服务端获取服务，服务端通过soa提供服务给客户端，客户端得到服务；第三种通信为客户端修改服务并通过soa发送至服务端，进一步的，服务端若接受修改，则发布此服务至soa，供客户端调用。
49.其中，如图6所示，现场通信模型域控制器间的socket通信协议由上至下依次为域控制器2中soa通过socket的通知事件pdu与域控制器1中soa通信、域控制器1中soa通过socket的获取pdu与域控制器2中soa通信、域控制器2中soa通过socket的发送pdu与域控制器1中soa通信、域控制器1中soa通过socket的设置pdu与域控制器2中soa通信。
50.以上，是对面向服务通信模型层103的通信模型的进一步说明，在具体操作中，本领域技术人员可以根据实际情况使用上述通信模型进行通信，此处不做限定。
51.在一些实施方式中，面向服务架构总线管理层104被配置成对面向服务架构通信数据进行处理以及对服务端和客户端的通信进行管理，面向服务架构总线管理层104包括soa服务权限管理模块、soa服务端/客户端连接管理模块、socket通信连接管理模块、socket通信协议配置模块、socket通信数据包封装模块和socket通信数据包解析模块，soa通信数据最终通过创建管理的socket完成跨域控制器的通信。
52.通过上述本发明的技术方案，在mcu上部署soa软件框架，通过socket上封装的私有通信协议实现服务端和客户端的网络通信，soa框架由接口定义语言层、代码生成工具、面向服务通信模型层和面向服务架构总线管理层组成，实现了一种可落地的基于mcu的soa，数据最终通过创建管理的socket完成跨域控制器的通信，使之成为整车soa的重要组成部分。
53.进一步，本发明基于上述用于微控制器mcu的面向服务架构的技术方案，还提供了一种面向服务架构的通信方法，用于服务端和客户端的信息通信，参阅附图7，图7是根据本发明的一种面向服务架构的通信方法的主要步骤流程示意图。如图7所示，本发明实施例中的面向服务架构的通信方法主要包括下列步骤s701至步骤s704。
54.步骤s701：服务端基于接口定义语言层的protobuf数据序列化协议定义soa通信数据和soa通信接口。
55.步骤s702：服务端和客户端基于代码生成工具层中的编译器生成soa通信数据的目标代码。
56.步骤s703：服务端和客户端基于代码生成工具层中的解析器解析soa通信接口，并基于面向服务通信模型以及代码生成工具层中的代码模板分别生成服务端和客户端的soa通信接口代码。
57.步骤s704：服务端与客户端基于生成的服务端和客户端的soa通信接口代码进行通信。
58.在本实施例中，步骤s701至步骤s704中所述的面向服务架构的通信方法具体内容，请参照本发明上述用于微控制器mcu的面向服务架构的技术方案实施例部分，此处不再复述。
59.需要指出的是，尽管上述实施例中将各个步骤按照特定的先后顺序进行了描述，但是本领域技术人员可以理解，为了实现本发明的效果，不同的步骤之间并非必须按照这样的顺序执行，其可以同时（并行）执行或以其他顺序执行，这些变化都在本发明的保护范围之内。
60.目前，高速车载千兆以太网已被纳入汽车主干网络，汽车的电子电器架构正经历着由传统分布式电子控制单元ecu架构向“中央计算平台+域控制器”架构转变。
61.本发明基于上述用于微控制器mcu的面向服务架构的技术方案，提供了一种车辆电子电器架构，该车辆电子电器架构包括中央计算平台、至少一个域控制器以及总线。
62.参阅附图8，图8是根据本发明的一个实施例的车辆电子电器架构的主要结构框图。如图8所示，本发明的一个实施例的车辆电子电器架构包括中央计算平台801、域控制器8021、域控制器8022、域控制器8023、域控制器8024和总线803。
63.其中，中央计算平台801被配置成包括至少一个基于mpu的智能控制器；域控制器802被配制成以mcu作为主控芯片，其中，mcu主控芯片被配置为采用上述用于微控制器mcu的面向服务架构的技术方案实施例所述的mcu；总线803被配置成连接智能控制器与域控制器的soa总线。
64.在本实施方式中，每个域控制器包括至少一个域控制器服务端、至少一个域控制器客户端和mcu soa。其中，域控制器服务端通过mcu soa发布提供的服务，域控制器客户端通过mcu soa请求服务。
65.在一些实施方式中，域控制器以车规级的mcu作为主控芯片，由can收发器，lin收发器，以太网收发器，gpio扩展器，开关检测等外围芯片组成，支持100base-t1/1000base-t1标准的车载以太网。
66.进一步地，域控制器的以太网络层次中，数据链路层支持时间敏感网络（time sensetive networking, tsn）协议标准；传输层支持传输控制协议(transmission control protocol, tcp)和用户数据包协议(user datagram protocol, udp)。
67.在一些实施方式中，车辆的整车车身控制，动力底盘控制将会被划分至若干域控制器，域控制器与ecu之间使用can通信。
68.在本实施方式中，中央计算平台包括智能座舱控制器、智能车载控制器以及智能驾驶控制器中至少一个，通常情况下智能座舱控制器是必要的，智能车控控制器和智能驾驶控制器可以根据实际情况选择安装。中央计算平台内的智能座舱控制器、智能车载控制器和智能驾驶控制器之间使用车载以太网通信。
69.在一些实施方式中，中央计算平台包括至少一个第一mpu智能控制器、至少一个第二mpu智能控制器和mpu总线。
70.参阅附图9，图9是根据本发明的一个实施例的中央计算平台的主要结构框图。如图9所示，中央计算平台包括第一mpu智能控制器901、第二mpu智能控制器902、mcu域控制器903、mcu域控制器904、mcu soa总线905和mpu soa总线906。
71.在一些实施方式中，第一mpu智能控制器901包括至少一个第一智能控制器服务端、至少一个第一智能控制器客户端和mcu soa。其中，智能控制器客户端基于mcu soa总线905请求mcu域控制器903和/或mcu域控制器904上的服务。
72.进一步地，第一mpu智能控制器901还包括mpu soa，第一mpu智能控制器901和第二
mpu智能控制器902之间通过mpu soa总线906通信连接。
73.在一些实施方式中，第二mpu智能控制器902包括至少一个智能控制器服务端、至少一个智能控制器客户端和mpu soa。第二mpu智能控制器902的智能控制器客户端可以通过第一mpu智能控制器901请求mcu域控制器903和/或mcu域控制器904上的服务。
74.mcu域控制器903和mcu域控制器904分别包括至少一个域控制器服务端、至少一个域控制器客户端和至少一个mcu soa。
75.在一些实施方式中，mcu域控制器上的域控制器服务端可以通过mcu soa总线发布提供的服务，mcu域控制器上的域控制器客户端可以通过mcu soa请求mcu soa 总线上已经发布的服务。
76.在另一些实施方式中，mpu智能控制器上的智能控制器客户端请求mcu域控制器上的服务时，若该mpu智能域控制器内有mcu soa，则可以直接通过自身已有的mcu soa完成服务请求；若该mpu智能域控制器内没有mcu soa，则可以利用自身有的mpu soa与其他同时包含mcu soa和mpu soa的mpu智能控制器通信，并将同时包含mcu soa和mpu soa的mpu智能控制器作为代理，实现对mcu域控制器服务的请求。
77.在上述车辆电子电器架构中的一些实施方式中，域控制器与中央计算平台之间使用车载以太网通信。
78.在另一些实施方式中，域控制器与中央计算平台之间使用车载以太网为主干网络通信，同时保留can通信用于功能安全等级要求特别高的信号。
79.进一步地，当所述车辆电子电器架构包括多个域控制器时，多个域控制器之间通过车载以太网通信，同时支持can通信。
80.通过上述“中央计算平台+域控制器”的车辆电子电器架构，使传统分散在各个ecu上的功能得以在域控制器上以服务的形式对外提供出去，可满足域控制器之间、域控制器与智能座舱控制器之间、智能驾驶控制器之间的soa通信，保证了整车soa的统一，为创建全车智能化场景服务奠定基础。
81.进一步，本发明还提供了一种驾驶设备。在根据本发明的一个驾驶设备的实施例中，驾驶设备可以包括驾驶设备本体和上述车辆电子电器架构实施例中所述的车辆电子电器架构。
82.本领域技术人员能够理解的是，本发明实现上述一实施例的方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器、随机存取存储器、电载波信号、电信信号以及软件分发介质等。
83.进一步，本发明还提供了一种电子设备。参阅附图10，电子设备包括处理器1001和存储装置1002，存储装置1002可以被配置成存储执行上述方法实施例的面向服务架构的通信方法的程序，处理器1001可以被配置成用于执行存储装置中的程序，该程序包括但不限于执行上述方法实施例的面向服务架构的通信方法的程序。为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该计算机
设备可以是包括各种电子设备形成的控制装置设备。
84.进一步，本发明还提供了一种计算机可读存储介质。在根据本发明的一个计算机可读存储介质实施例中，计算机可读存储介质可以被配置成存储执行上述方法实施例的面向服务架构的通信方法的程序，该程序可以由处理器加载并运行以实现上述面向服务架构的通信方法。为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该计算机可读存储介质可以是包括各种电子设备形成的存储装置设备，可选的，本发明实施例中计算机可读存储介质是非暂时性的计算机可读存储介质。
85.至此，已经结合附图所示的一个实施方式描述了本发明的技术方案，但是，本领域技术人员容易理解的是，本发明的保护范围显然不局限于这些具体实施方式。在不偏离本发明的原理的前提下，本领域技术人员可以对相关技术特征作出等同的更改或替换，这些更改或替换之后的技术方案都将落入本发明的保护范围之内。