基于SOA架构的API开发方法、装置、设备及存储介质与流程

文档序号:29627340发布日期:2022-04-13 14:50阅读:392来源:国知局
基于SOA架构的API开发方法、装置、设备及存储介质与流程
基于soa架构的api开发方法、装置、设备及存储介质
技术领域
1.本技术涉及汽车技术领域,特别涉及一种基于soa(service-oriented architecture,面向服务结构)架构的api(application programming interface,应用程序接口)开发方法、装置、设备及存储介质。


背景技术:

2.相关技术中,通常是基于信号对车辆进行api开发,具体地:首先获取功能需求,然后将独立的功能硬件软件耦合至一个控制单元中,最后通过标准的协议接入整车的电子电器架构。然而,相关技术中基于信号的开发方式,导致软件与硬件耦合,无法满足上层应用软件的快速开发迭代的需求。


技术实现要素:

3.本技术提供一种基于soa架构的api开发方法、装置、设备及存储介质,以解决相关技术中基于信号的开发方式,导致软件与硬件耦合程度较高,无法满足上层应用软件的快速开发迭代的需求等问题。
4.本技术第一方面实施例提供一种基于soa架构的api开发方法,包括以下步骤:获取车辆的面向服务架构soa架构中多个硬件资源;根据所述多个硬件资源的型号匹配所述多个硬件资源之间的差异性;在以太网关中对所述多个硬件资源之间的差异性进行隔离,生成最优运行环境,并在所述最优运行环境下,通过所述以太网关将所述车辆的所有软件功能集成为服务api,将所述服务api映射至所述soa架构中,且通过所述以太网关向调用方提供api接口。
5.进一步地,在根据所述多个硬件资源的型号匹配所述多个硬件资源之间的差异性之前,还包括:对所述多个硬件资源进行硬件资源分析和硬件资源用例分析,以得到api接口的目标需求;基于所述api接口的目标需求设计所述api接口。
6.进一步地,在获取车辆的面向服务架构soa中多个硬件资源之前,还包括:获取所述车辆的功能清单、配置表、整车网络拓扑、功能安全需求表、功能规范与性能指标;根据所述功能清单、所述配置表、所述整车网络拓扑、所述功能安全需求表、所述功能规范与性能指标设计所述车辆的通信架构。
7.进一步地,在获取车辆的soa架构中多个硬件资源之前,还包括:获取所述车辆的整车布置信息和零部件接口信息;根据所述功能清单、所述配置表、功能安全需求表、所述整车布置信息和所述零部件接口信息设计所述车辆的物理接口。
8.本技术第二方面实施例提供一种基于soa架构的api开发装置,包括:获取模块,用于获取车辆的面向服务架构soa架构中多个硬件资源;匹配模块,用于根据所述多个硬件资源的型号匹配所述多个硬件资源之间的差异性;开发模块,用于在以太网关中对所述多个硬件资源之间的差异性进行隔离,生成最优运行环境,并在所述最优运行环境下,通过所述以太网关将所述车辆的所有软件功能集成为服务api,将所述服务api映射至所述soa架构
中,且通过所述以太网关向调用方提供api接口。
9.进一步地,还包括:第一设计模块,用于在根据所述多个硬件资源的型号匹配所述多个硬件资源之间的差异性之前,对所述多个硬件资源进行硬件资源分析和硬件资源用例分析,以得到api接口的目标需求;基于所述api接口的目标需求设计所述api接口。
10.进一步地,还包括:第二设计模块,用于在获取车辆的面向服务架构soa架构中多个硬件资源之前,获取所述车辆的功能清单、配置表、整车网络拓扑、功能安全需求表、功能规范与性能指标;根据所述功能清单、所述配置表、所述整车网络拓扑、所述功能安全需求表、所述功能规范与性能指标设计所述车辆的通信架构。
11.进一步地,还包括:第三设计模块,用于在获取车辆的soa架构中多个硬件资源之前,获取所述车辆的整车布置信息和零部件接口信息;根据所述功能清单、所述配置表、功能安全需求表、所述整车布置信息和所述零部件接口信息设计所述车辆的物理接口。
12.本技术第三方面实施例提供一种电子设备,包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述程序,以实现上述实施例所述的基于soa架构的api开发方法。
13.本技术第四方面实施例提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行,以用于实现上述实施例所述的基于soa架构的api开发方法。
14.由此,本技术至少具有如下有益效果:
15.将车内软件功能形成标准的服务api,并通过车载以太网关向调用方提供api接口,调用方使用api接口进行上层应用开发,实现软硬解耦,满足上层应用软件的快速开发迭代的需求,有效避免调用方直接接入执行器、传感器、legacy ecu强耦合方式。由此,解决了相关技术中基于信号的开发方式,导致软件与硬件耦合程度较高,无法满足上层应用软件的快速开发迭代的需求等技术问题。
16.本技术附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本技术的实践了解到。
附图说明
17.本技术上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
18.图1为相关技术中基于分布式电子架构软件开发方式;
19.图2为根据本技术实施例提供的soa电子架构软件开发方式;
20.图3为根据本技术实施例提供的基于soa架构的api开发方法的流程图;
21.图4为根据本技术实施例提供的服务api调用流程图;
22.图5为根据本技术实施例提供的基于soa架构的api开发装置的示例图;
23.图6为根据本技术实施例提供的电子设备的结构示意图。
具体实施方式
24.下面详细描述本技术的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本技术,而不能理解为对本技术的限制。
25.随着汽车行业向新四化转变,软件定义汽车概念的提出,电子架构作为新四化的基础技术,行业普遍认为架构定义软件。因此,电子架构的开发方式需从如图1所示的相关技术中基于信号的开发的架构,即软硬耦合,转变为面向服务的开发,即如图2所示的soa架构,实现软硬解耦。soa架构首先应用于互联网it行业,取得了成功;随着行业趋势变化,汽车行业整体进行soa架构的研发,但由于汽车存在重安全、信息传输速率、特有的通讯协议等特点,需要对互联网soa进行适应性开发,满足汽车行业的要求,行业内各个公司对soa的开发都处于起步阶段,并无统一或绝对正确的标准。
26.为实现汽车软硬解耦,本技术实施例研发了针对汽车soa架构开发中api技术,将车内软件功能形成标准的服务api,并通过车载以太网关向调用方提供api接口,调用方使用api接口进行上层应用开发,改变了传统调用方直接接入执行器、传感器、legacy ecu强耦合的方式。
27.下面将参考附图描述本技术实施例的基于soa架构的api开发方法、装置、车辆及存储介质。针对上述背景技术中提到的相关技术中基于信号的开发方式,导致软件与硬件耦合程度较高,无法满足上层应用软件的快速开发迭代的需求的问题,本技术提供了一种基于soa架构的api开发方法,在该方法中,将车内软件功能形成标准的服务api,并通过车载以太网关向调用方提供api接口,调用方使用api接口进行上层应用开发,实现软硬解耦,满足上层应用软件的快速开发迭代的需求,有效避免调用方直接接入执行器、传感器、legacy ecu强耦合方式。由此,解决了相关技术中基于信号的开发方式,导致软件与硬件耦合程度较高,无法满足上层应用软件的快速开发迭代的需求等技术问题。
28.具体而言,图3为本技术实施例所提供的一种基于soa架构的api开发方法的流程示意图。
29.如图3所示,该基于soa架构的api开发方法包括以下步骤:
30.在步骤s101中,获取车辆的面向服务架构soa架构中多个硬件资源。
31.其中,多个硬件资源可以包括对传感器和执行器等硬件资源。
32.在步骤s102中,根据多个硬件资源的型号匹配多个硬件资源之间的差异性。
33.可以理解的是,如图4所示,本技术实施例可以对传感器和执行器等硬件资源进行抽象,匹配和协调不同型号/不同厂家硬件差异,提供稳定的上层api接口,开发服务的目的是用于满足上层业务应用需要。
34.在本实施例中,在根据多个硬件资源的型号匹配多个硬件资源之间的差异性之前,还包括:对多个硬件资源进行硬件资源分析和硬件资源用例分析,以得到api接口的目标需求;基于api接口的目标需求设计api接口。
35.具体而言,api的设计具体包括:
36.(1)硬件资源分析:完成型号信息,关键组件、原理和功能描述关键属性梳理;完成包括数据类型ad/di/pwm/can/lin、单位和取值范围的输入输出梳理;
37.(2)硬件资源用例分析,从业务、用户体验和功能安全等维度分析服务使用场景,得到服务接口需求;
38.(3)服务接口设计,定义服务名称、prc类型(event、r&r method、f&f method等)、api名称等内容。
39.在步骤s103中,在以太网关中对多个硬件资源之间的差异性进行隔离,生成最优
运行环境,并在最优运行环境下,通过以太网关将车辆的所有软件功能集成为服务api,将服务api映射至soa架构中,且通过以太网关向调用方提供api接口。
40.可以理解的是,基于体系开发的soa电子架构平台将整车功能按照功能域进行划分,同时增加软件平台层,即区域以太网关,且soa的服务基于以太网开发,从而可以基于汽车soa电子架构,通过服务api,向调用方提供api接口,实现软硬解耦,赋能上层应用软件的快速开发迭代。
41.具体而言,为了实现冗余备份,可以进行安全关键服务分布式部署;为使系统运行更高效,硬件资源可以就近服务化;在以太网关层实现硬件差异性隔离,保证上层计算可靠稳定。在完成开发后,最终输出服务的设计说明书,提供给调用方用以组合应用。
42.在本实施例中,在获取车辆的面向服务架构soa中多个硬件资源之前,还包括:获取车辆的功能清单、配置表、整车网络拓扑、功能安全需求表、功能规范与性能指标;根据功能清单、配置表、整车网络拓扑、功能安全需求表、功能规范与性能指标设计车辆的通信架构。
43.可以理解的是,本技术实施例可以根据整车功能清单和配置表、整车网络拓扑方案、功能安全需求、功能规范/性能指标、标准/法规/规范完成通信架构的设计。具体如下:
44.(1)整车通讯架构方案,用以整车级架构设计约束,制定设计原则/数据流/负载率/倒换机制/关键协议;
45.(2)can/lin/以太通信协议/规范,用以规范ecu通信设计关键参数,制定someip/uds/doip/mqtts/rtsp/https/gptp等,定义部件mac/ip/vlan/port/qos/协议选择,定义部件can/canfd/lin/以太通信机制;
46.(3)整车网络管理设计方案,用以规范ecu休眠唤醒设计,制定autosar/udp/局域网络管理策略;
47.(4)整车通讯安全设计方案,用以规范ecu通讯安全涉及,制定secoc/e2e/数字认证设计策略;
48.(5)诊断设计方案,用以规范系统/部件诊断设计,制定近端诊断/远端诊断方案;
49.(6)can/fd/lin/以太通讯矩阵方案,用以定义部件间通讯接口,完成dbc/lbf/arxml/车云接口设计。
50.在本实施例中,在获取车辆的soa架构中多个硬件资源之前,还包括:获取车辆的整车布置信息和零部件接口信息;根据功能清单、配置表、功能安全需求表、整车布置信息和零部件接口信息设计车辆的物理接口。
51.可以理解的是,本技术实施例可以根据整车功能清单和配置表、零部件接口信息表、功能安全需求表、整车初步布置方案完成物理接口设计。具体如下:
52.(1)网络拓扑设计,用以支撑网络通讯协议制定,物理拓扑方案设计,用以服务部署方案制定,设计原则为实现执行器、传感器就近接入,以太/can/硬线需双接与冗余,主要信号传输需备份链路;
53.(2)整车原理方案设计,用以整车线束、硬件接口定义、控制器布置设计;
54.(3)电源管理方案设计,用以整车保险丝、继电器对用电器的分配,关键负载双路供电,安全负载与常规负载供电隔离;实现整车级别低压能量检测和管理。
55.综上,本技术实施例可以通过soa的方式,同时结合汽车行业的需求特点,可实现
软硬解耦的需求,使车辆智能化功能可以快速通过调用api实现,车辆上市后,也可通过ota的方式进行功能快速组合,通过车辆中集成的应用市场进行订阅,可免费,可付费,提升用户体验感及粘度。
56.根据本技术实施例提出的基于soa架构的api开发方法,将车内软件功能形成标准的服务api,并通过车载以太网关向调用方提供api接口,调用方使用api接口进行上层应用开发,实现软硬解耦,满足上层应用软件的快速开发迭代的需求,有效避免调用方直接接入执行器、传感器、legacy ecu强耦合方式。
57.其次参照附图描述根据本技术实施例提出的基于soa架构的api开发装置。
58.图5是本技术实施例的基于soa架构的api开发装置的方框示意图。
59.如图5所示,该基于soa架构的api开发装置10包括:获取模块100、匹配模块200和开发模块300。
60.其中,获取模块100用于获取车辆的面向服务架构soa架构中多个硬件资源;匹配模块200用于根据多个硬件资源的型号匹配多个硬件资源之间的差异性;开发模块300用于在以太网关中对多个硬件资源之间的差异性进行隔离,生成最优运行环境,并在最优运行环境下,通过以太网关将车辆的所有软件功能集成为服务api,将服务api映射至soa架构中,且通过以太网关向调用方提供api接口。
61.进一步地,本技术实施例的装置10还包括:第一设计模块。其中,第一设计模块用于在根据多个硬件资源的型号匹配多个硬件资源之间的差异性之前,对多个硬件资源进行硬件资源分析和硬件资源用例分析,以得到api接口的目标需求;基于api接口的目标需求设计api接口。
62.进一步地,本技术实施例的装置10还包括:第二设计模块。其中,第二设计模块用于在获取车辆的面向服务架构soa架构中多个硬件资源之前,获取车辆的功能清单、配置表、整车网络拓扑、功能安全需求表、功能规范与性能指标;根据功能清单、配置表、整车网络拓扑、功能安全需求表、功能规范与性能指标设计车辆的通信架构。
63.进一步地,本技术实施例的装置10还包括:第三设计模块。其中,第三设计模块用于在获取车辆的soa架构中多个硬件资源之前,获取车辆的整车布置信息和零部件接口信息;根据功能清单、配置表、功能安全需求表、整车布置信息和零部件接口信息设计车辆的物理接口。
64.需要说明的是,前述对基于soa架构的api开发方法实施例的解释说明也适用于该实施例的基于soa架构的api开发装置,此处不再赘述。
65.根据本技术实施例提出的基于soa架构的api开发装置,将车内软件功能形成标准的服务api,并通过车载以太网关向调用方提供api接口,调用方使用api接口进行上层应用开发,实现软硬解耦,满足上层应用软件的快速开发迭代的需求,有效避免调用方直接接入执行器、传感器、legacy ecu强耦合方式。
66.图6为本技术实施例提供的电子设备的结构示意图。该电子设备可以包括:
67.存储器601、处理器602及存储在存储器601上并可在处理器602上运行的计算机程序。
68.处理器602执行程序时实现上述实施例中提供的基于soa架构的api开发方法。
69.进一步地,电子设备还包括:
70.通信接口603,用于存储器601和处理器602之间的通信。
71.存储器601,用于存放可在处理器602上运行的计算机程序。
72.存储器601可能包含高速ram(random access memory,随机存取存储器)存储器,也可能还包括非易失性存储器,例如至少一个磁盘存储器。
73.如果存储器601、处理器602和通信接口603独立实现,则通信接口603、存储器601和处理器602可以通过总线相互连接并完成相互间的通信。总线可以是isa(industry standard architecture,工业标准体系结构)总线、pci(peripheral component,外部设备互连)总线或eisa(extended industry standard architecture,扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示,图6中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
74.可选的,在具体实现上,如果存储器601、处理器602及通信接口603,集成在一块芯片上实现,则存储器601、处理器602及通信接口603可以通过内部接口完成相互间的通信。
75.处理器602可能是一个cpu(central processing unit,中央处理器),或者是asic(application specific integrated circuit,特定集成电路),或者是被配置成实施本技术实施例的一个或多个集成电路。
76.本技术实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如上的基于soa架构的api开发方法。
77.在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或n个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
78.此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本技术的描述中,“n个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
79.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更n个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本技术的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本技术的实施例所属技术领域的技术人员所理解。
80.应当理解,本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,n个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如,如果用硬件来实现和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列,现场可编程门阵列等。
81.本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括方法实施例的步骤之一或其组合。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1