CN117519783B - 一种产品开发包与操作系统和硬件分离的方法及系统 - Google Patents

一种产品开发包与操作系统和硬件分离的方法及系统 Download PDF

Info

Publication number
CN117519783B
CN117519783B CN202410023629.1A CN202410023629A CN117519783B CN 117519783 B CN117519783 B CN 117519783B CN 202410023629 A CN202410023629 A CN 202410023629A CN 117519783 B CN117519783 B CN 117519783B
Authority
CN
China
Prior art keywords
service
layer
function
interface
product
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202410023629.1A
Other languages
English (en)
Other versions
CN117519783A (zh
Inventor
贾灵
王薪宇
刘伟
赵国凯
冯诗敏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lierda Science & Technology Group Co ltd
Original Assignee
Lierda Science & Technology Group Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lierda Science & Technology Group Co ltd filed Critical Lierda Science & Technology Group Co ltd
Priority to CN202410023629.1A priority Critical patent/CN117519783B/zh
Publication of CN117519783A publication Critical patent/CN117519783A/zh
Application granted granted Critical
Publication of CN117519783B publication Critical patent/CN117519783B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/20Software design

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本发明一种产品开发包与操作系统和硬件分离的方法及系统。解决了现有产品开发难度高、任务量大,产品应用与底层操作系统、硬件分离不彻底的问题。将系统分离成产品开发包、平台抽象层和BSP层;产品开发包分层为行业解决方案、产品通用功能库和应用服务层,功能库将产品功能抽象模块化形成的功能函数,应用服务层将程序功能封装形成的服务,行业解决方案组合调用功能函数形成产品,功能函数通过调用服务实现;平台抽象层将操作系统和硬件设备进行抽象提供统一接口,服务通过接口访问BSP层底层系统和硬件。利用产品开发包形式进行功能组合来开发产品,不需关注具体的复杂实现,提供零代码或低代码开发效果,简化开发流程,降低开发难度。

Description

一种产品开发包与操作系统和硬件分离的方法及系统
技术领域
本发明涉及软件工程设计技术领域,尤其是涉及一种产品开发包与操作系统和硬件分离的方法及系统。
背景技术
嵌入式系统在各种领域都有广泛的应用,包括工业控制、消费电子、医疗设备等。随着技术的发展,嵌入式系统的硬件和软件变得越来越复杂,越来越多的应用需要在不同的硬件平台上运行。然而,由于硬件平台的差异,开发人员需要针对不同的硬件平台编写不同的代码,这大大增加了开发和维护的难度。因此,如何实现嵌入式应用与系统和硬件的分离,对硬件和软件进行有效的抽象和管理,使得应用可以在不同的硬件平台上运行,成为了一个亟待解决的问题。
在传统的嵌入式系统中,应用层直接依赖于硬件层,这导致硬件和软件紧密耦合,难以维护和升级。此外,不同的硬件设备需要有不同的应用软件,这增加了开发和维护的成本。因此,需要一种方式将应用层与硬件层分离,以实现硬件的抽象和通用化。
嵌入式应用与硬件分层是一种设计方法,通过将整个系统划分为若干个层次,以实现各层之间的独立开发和协同工作。这种结构通常包括硬件层、驱动层、操作系统层和应用层。其中,
硬件层:这是整个嵌入式系统的基础,涉及到单片机及其接口等的编程和设计。开发者需要对硬件有深入的理解和操作能力。
驱动层:这一层的主要任务是提供硬件的驱动程序,使得上层软件能够更好地访问和控制硬件设备。
操作系统层:这一层提供了操作系统的功能,包括进程管理、内存管理、文件系统等。通过操作系统,开发者可以更有效地管理系统资源,并创建出复杂的应用程序。
应用层:这是最终用户直接接触到的层次,包括各种应用程序和界面。这一层的设计与用户的交互密切相关,需要考虑用户体验和界面设计等因素。
但目前这种设计方法还存在以下缺点:
1.嵌入式产品应用与底层操作系统、硬件分离不彻底,模块化程度低,程序复用率低,跨平台能力低。
2.产品开发者需要深入了解产品原理,二次开发任务量大,开发难度大,难以满足快速开发产品需求。
发明内容
本发明主要是解决了现有技术中产品开发难度高、任务量大,以及产品应用与底层操作系统、硬件分离不彻底,模块化程度低、程序复用率低、跨平台能力低的问题,提供了一种产品开发包与操作系统和硬件分离的方法及系统。
本发明的上述技术问题主要是通过下述技术方案得以解决的:一种产品开发包与操作系统和硬件分离的方法,包括:
将系统分离成包括产品开发包的应用开发,以及包括平台抽象层和BSP层的设备开发;
将产品开发包分层为行业解决方案、产品通用功能库和应用服务层,所述产品通用功能库将产品功能抽象模块化形成功能函数,所述应用服务层将程序功能封装形成服务,行业解决方案组合调用功能函数形成产品,功能函数通过调用服务实现;
所述平台抽象层将操作系统和硬件设备进行抽象,为应用开发和BSP层提供统一接口,所述服务通过平台抽象层提供的接口访问BSP层底层系统和硬件。
本发明方法根据产品开发将系统分层架构分成应用开发和设备开发,应用开发只需关注业务逻辑开发,开发应用不需要关注底层实现,只需了解有哪些接口。设备开发开发硬件和系统相关的底层功能。系统软件按照功能不同划分为多个层次,分层从上到下依次为产品开发包、平台抽象层、BSP层,各层之间通过定义的抽象接口进行通信和协作,实现系统的解耦和高可扩展性,同时也方便不同团队之间的协作开发。
作为一种优选方案,设定服务对应一个服务对象实例,服务包括多种能力,服务能力对应设置服务处理函数,功能函数发起服务调用,执行对应的服务处理函数,调用服务提供的能力。
设置每个服务在程序中对应一个服务对象实例,通过service_id唯一标识,一个服务具备多种能力,用ability_id标识,服务能力的控制参数为ability_params,服务能力的处理函数为服务处理函数,由用户开发注册,含多个能力处理分支,每个分支为某个服务能力具体的复杂实现。产品功能函数发起服务调用,使用服务对象实例、ability_id、ability_params作为形参,通过服务分发机制分配一个线程,执行对应的服务处理函数,调用服务提供的能力。
作为一种优选方案,所述的行业解决方案组合调用功能函数形成产品,功能函数通过调用服务实现,具体包括:
进行初始化,包括设备进行OS初始化、设备驱动初始化、应用服务初始化和产品功能库初始化;
当有外部触发或检测到触发状态,触发产品功能时,调用产品功能库中对应的功能函数;
调用服务调用函数,访问服务提供的能力;
进行服务分发,对服务分配线程,执行服务处理函数。
本方案在上电后进行初始化,初始化具体包括,
OS初始化,内部调用第三方OS的初始化函数,完成OS系统环境初始化。
设备驱动初始化,完成设备驱动框架底层依赖的注册。
应用服务初始化,注册底层依赖接口,注册服务能力处理函数,创建线程池,创建服务的实例函数,将服务绑定到线程池。
产品功能库各类APP初始化,加载依赖的服务,获取服务的实例对象。
初始化完成后,程序正常运行,可选择订阅服务事件,订阅当前或其他服务的事件,注册事件回调函数。当订阅事件发生时,调用注册的事件回调函数。
当有外部触发或检测到触发状态,触发产品功能时,调用产品通用功能库中对应的功能函数app_xxxfunc();产品通用功能库功能函数通过应用服务提供的能力实现,服务屏蔽了产品功能的复杂实现逻辑,对上提供服务调用这种简单的接口,产品通用功能库的功能函数app_xxxfunc()通过执行简单的服务调用,以类似发送命令的方式,访问服务提供的能力。
进一步调用服务调用函数service_call(),通过形参传入服务对象实例、ability_id、ability_params、输出回调函数,访问服务提供的能力。服务的执行结果可通过输出回调函数获取。
发起服务调用后,进入服务分发环节。先向服务绑定的线程池发送消息,若是同步调用,接下来阻塞等待输出信号,若是异步调用,直接返回退出。线程池收到消息后,分配一个空闲线程,执行服务注册的服务处理函数。
作为一种优选方案,所述的服务通过平台抽象层提供的接口访问BSP层底层系统和硬件,具体包括:
进行服务分布式状态判断,进行本地调用服务或远程调用服务;
调用服务包括:
执行服务处理函数的能力分支,
服务能力调用平台抽象层接口,
平台抽象层接口调用BSP层接口;
服务处理函数执行结束,进行调用机制判断,输出结果信号。
在服务调用前还进行服务分布式状态判断,判断为本地调用服务还是远程调用服务,若是本地调用服务,采用如下步骤:
S501.执行服务处理函数的能力分支。服务处理函数的能力分支是产品功能的具体复杂实现,每一个服务能力对应一个处理分支,根据传入的ability_id区分执行。
S502.服务能力调用平台抽象层接口。调用平台抽象层接口包括OS内核抽象层接口和设备抽象层接口。
S503.平台抽象层接口调用BSP层接口。OS内核抽象层接口底层是调用第三方OS内核接口,设备抽象层接口底层是调用芯片原厂驱动库接口。
若是远程调用服务,采用如下步骤:
S511.发现端网络通信:发送服务调用请求。
S512.发布端收到服务调用请求,解析出所需调用服务。
S513.发布端从本地服务列表中找到该服务对象实例。
S514.采用本地调用步骤,调用服务。
S515.发布端网络通信:发送服务调用响应。
S516.发现端收到服务调用响应。
服务处理函数执行结束,返回输出结果。调用输出回调函数,形参传入服务输出结果。
进行调用机制判断,即判断同步调用还是异步调用,若是同步调用方式,发送输出信号,之前等待输出信号的地方退出阻塞。
作为一种优选方案,所述步骤的平台抽象层接口调用BSP层接口,具体包括:
a.定义设备的抽象层接口和BSP层接口,抽象层接口与BSP层接口类型对应;
b.对设备和硬件进行初始化;
c.调用设备的抽象层接口,访问控制设备;
d.抽象层接口调用对应同类型的BSP层接口;
e. BSP层接口调用芯片原厂驱动库,完成硬件访问控制。
设备抽象层基于底层硬件为应用开发提供抽象的驱动访问接口,实现对硬件设备的控制和管理,屏蔽硬件设备的差异性。设备抽象层采用桥接设计模式,用于将抽象接口和它的实现接口分离,使得两者可以独立的变化。其中抽象接口对应设备抽象层接口,实现接口对应BSP层接口。具体的对接口进行定义,包括
定义设备的抽象层接口,假设使用device_ops结构体封装,包含不局限于以下接口:device_open、device_read、device_write、device_ctrl、device_close,接口对应实例函数。
定义设备的BSP层接口,假设使用bsp_ops结构体封装,包含不局限于以下接口:open、read、write、ctrl、close;BSP层接口包含实例函数和抽象层接口一样。BPS层接口的实例函数使用芯片原厂的驱动库来实现。抽象层接口的实例函数中,同类型的实例函数其内部调用BSP层接口里对应同类型的实例函数。
定义设备结构体,定义设备抽象层注册接口,定义设备抽象层查找接口。
对设备和硬件进行初始化,具体包括,
创建设备对象实例,用芯片原厂接口完成BSP层接口内功能;
调用设备注册接口,注册设备,将设备对象实例添加到设备链表里;
调用设备查找接口,根据设备名称,从设备链表里获取设备对象实现;
调用设备抽象层接口的device_open接口,初始化设备;
device_open接口进一步调用BSP层接口里的open接口;
BSP层接口里的open接口调用芯片原厂驱动库,完成硬件初始化。
调用设备的抽象层接口实例函数,访问控制设备,具体包括:
调用设备抽象层接口的device_read、device_write、device_ctrl接口,去访问控制设备;
抽象层接口调用对应同类型的BSP层接口,具体包括:
抽象层接口的device_read、device_write、device_ctrl接口内部调用BSP层接口里的read、write、ctrl接口;
BSP层接口调用芯片原厂驱动库,实现硬件访问控制;
当设备不再使用时,调用设备抽象层接口的device_close接口,device_close接口内部调用BSP层接口的close接口,最终调用芯片原厂驱动库,完成硬件去初始化。
一种产品开发包与操作系统和硬件分离的系统,包括:应用开发的产品开发包,设备开发的平台抽象层和BSP层,
产品开发包,包含行业解决方案、产品通用功能库和应用服务层,产品通用功能库包括将产品功能抽象模块化形成的功能函数,行业解决方案组合调用功能函数形成产品,应用服务层包括程序功能封装形成的服务,功能函数通过调用服务实现;
平台抽象层,将操作系统和硬件设备进行抽象,为应用开发和BSP层提供统一接口,服务通过平台抽象层提供的接口访问BSP层底层系统和硬件。
本发明系统分层架构将产品开发分成应用开发和设备开发,应用开发只需关注业务逻辑开发,开发应用不需要关注底层实现,只需了解有哪些接口。设备开发开发硬件和系统相关的底层功能。系统软件按照功能不同划分为多个层次,分层从上到下依次为产品开发包、平台抽象层、BSP层,各层之间通过定义的抽象接口进行通信和协作,实现系统的解耦和高可扩展性,同时也方便不同团队之间的协作开发。
产品开发包,包含多种行业解决方案、产品通用功能库和应用服务层的低代码级别方案,可根据用户要求的产品类型、物模型定义、硬件需求生成适配的开发包,这种利用产品开发包进行组合式应用开发,简化开发流程,让产品开发者进一步降低开发成本和难度,提升产品的开发效率。产品开发包通过应用服务层实现应用开发与操作系统和硬件的分离,集成通用产品功能库和行业解决方案,实现了应用的低代码开发能力。
行业解决方案,具体为提供面向某行业产品标准功能的完整实现方案,用户可零代码开发或低代码开发产品。行业解决方案包括但不限于电工、照明、家用厨卫、户外出行、节能能源、智能锁、运动健康等行业领域。其将产品通用功能库中的功能函数组合在一起调用,形成不同的产品,使得用户开箱即用,实现零代码开发。若用户想添加新功能,只需将产品通用功能库中的功能函数添加到程序调度器中,实现低代码扩展新功能。
产品通用功能库,提炼各类产品通用功能,将产品功能分类抽象并模块化,制作形成一系列功能函数库,包括但不限于开关阀控、计量功能、通信功能、安全防盗等;用户只需了解有哪些可用的功能函数,不需要研究具体的复杂实现原理,降低产品开发难度。产品功能函数内部通过服务调用的形式调用一个或多个服务能力实现。
应用服务层,将常用程序功能封装成独立的服务,这些服务支撑实现一个个具体的产品功能,分离解耦应用开发和设备开发。服务包括但不限于电源管理服务、网络管理服务、位置服务、文件系统服务、事件管理服务、OTA服务、安全服务、参数管理服务、IoT云服务等。当用户需要开发某类产品功能时,可直接选择调用相应的应用服务能力,应用服务能力内部调用底层操作系统及硬件来具体实现功能,用户无需关心具体复杂的实现过程。
平台抽象层,硬件设备和OS系统组成的平台,通过将操作系统和硬件设备进行抽象,对上层应用开发和BSP层提供统一接口,形成上层应用与BSP层的访问桥梁,达到产品开发包与操作系统和硬件分离的效果。
BSP层,通过平台抽象层与产品开发包分离,当用户开发时需要使用不同的操作系统以及芯片平台时,可以进行更换适配但不需要更改上层应用程序,避免出现重复开发资源浪费的问题,实现跨平台。
本发明将系统软件分层,产品开发包中的应用服务层使应用开发和设备开发分离,平台抽象层使得设备抽象与BSP层分离,起到了屏蔽硬件差异的作用。系统每一层按类型和功能抽象出不同的模块,模块化程度高且可自定义添加扩展,方便不同部门间开发协作。
应用开发和设备开发分离,使得应用开发与底层硬件、操作系统隔离解耦,可灵活配置不同操作系统、硬件平台,应用程序可跨平台复用。
作为一种优选方案,所述服务对应一个服务对象实例,具备多种能力,服务能力包括服务处理函数,功能函数发起服务调用,执行对应的服务处理函数,调用服务提供的能力。
具体的每个服务在程序中对应一个服务对象实例,通过service_id唯一标识,一个服务具备多种能力,用ability_id标识,服务能力的控制参数为ability_params,服务能力的处理函数为服务处理函数,由用户开发注册,含多个能力处理分支,每个分支为某个服务能力具体的复杂实现。产品功能函数发起服务调用,使用服务对象实例、ability_id、ability_params作为形参,通过服务分发机制分配一个线程,执行对应的服务处理函数,调用服务提供的能力。
作为一种优选方案,所述服务通过设备形式连接在设备总线上,设备基于设备总线调用其他设备的服务。
本发明服务应用层包括将常用程序功能封装形成独立的服务,开发某类产品功能时,通过调用相应的应用服务能力。该服务的形式具备分布式功能,使得设备不仅可访问本地服务,也可以访问其他设备发布的服务,且支持同步和异步方式调用服务。分布式应用服务具体为,在同一局域网中的物联网设备之间搭建一条虚拟的设备总线,单个物联网设备可以分解为多个应用服务连接到设备总线上,由此呈现给用户一个大的虚拟设备,单个设备可以基于设备总线调用其他设备的应用服务,甚至可以对多个设备上的应用服务进行组合,实现跨设备调用,从而构建更复杂的应用,实现更复杂的功能,互联互通便捷,达到分布式应用服务的目的。
物联网设备根据功能分为两类:服务发布端,服务发现端,一个设备运行同时具备服务发布和服务发现功能。
服务发布:设备将自身具备的同类功能提炼为服务,可用service_id唯一标识。每种服务提供多种能力,可用ability_id唯一标识。每个能力对应一个能力实现函数,可用ability_func标识。设备可将自己具备多种能力的服务发布到设备总线上。比如智能灯具可以提炼为灯控服务,具备打开灯、关闭灯、调节灯光强度、调节灯光色彩等多种能力。
服务发现:设备可以从设备总线上搜索其它设备发布的服务,并根据自身需要调用其它设备中服务的能力。
作为一种优选方案,所述平台抽象层包括OS内核抽象层和硬件设备抽象层,
OS内核抽象层,对操作系统内核接口进行抽象,以适配不同操作系统内核;
硬件设备抽象层,包括IoT模块抽象和控制器抽象,其中,
IoT模块抽象,对IoT模块进行抽象,建立设备模型,提供访问设备的统一抽象接口;
控制器抽象,对不同架构控制器外设接口和内部资源进行抽象,生成控制器设备,提供访问设备的统一抽象接口。
本方案中硬件设备(包括主控芯片和外围IoT模块)和OS系统的组合称为平台。硬件设备抽象层包括IoT模块抽象和控制器抽象。OS内核抽象层对操作系统功能进行抽象。通过将操作系统和硬件设备进行抽象,对上层应用开发提供统一接口,形成上层应用与BSP层的访问桥梁,达到产品开发包与操作系统和硬件分离的效果。
IoT模块抽象,指主控芯片周围外接设备,如传感器模块、通信模块、存储模块、输入和显示类模块、电源管理模块等。对IoT模块进行抽象,建立设备模型,提供访问设备的统一抽象接口,例如,所有LED指示灯的功能都包括普通亮灭、颜色控制、周期闪烁控制等,将这些通用功能接口抽象出来形成模块化的LED设备,避免重复造轮子,不同的LED硬件使用相同接口,屏蔽底层实际硬件差异。常见的IoT抽象模型包括但不限于网络设备、sensor类设备、LED设备、Light设备、输入设备、Display设备等设备模型。
控制器抽象,对不同架构控制器外设接口和内部资源进行抽象,生成控制器设备,提供访问设备的统一抽象接口,以屏蔽不同芯片原厂平台控制器使用上的差异。外设接口通常包括但不限于GPIO、UART、SPI、IIC、PWM、CAN、USB等,内部资源通常包括但不限于FLASH、Timer、RTC、WATCH、中断管理。
OS内核抽象层,对操作系统内核接口进行抽象,以适配不同原厂平台的操作系统内核。适配Linux、RTOS等类型操作系统提供一个统一的系统接口,包括但不限于消息队列、信号量、互斥量等常用功能,建立产品开发包与底层操作系统之间的访问桥梁。
作为一种优选方案,所述BSP层包括第三方OS和芯片原厂驱动库。
具体的,第三方OS为主流的linux、RTOS内核。
芯片原厂驱动库,主控芯片原厂提供的开发库,对主控芯片上的资源进行了封装,用户不需要深入理解寄存器和汇编相关内容即可访问主控的外设和内部资源,如stm32芯片的HAL库。
因此,本发明的优点是:
1.利用产品开发包形式进行功能组合来开发产品,开发人员只需了解应用接口,不需要关注具体的复杂实现,提供零代码或低代码开发效果,简化开发流程,降低开发难度。
2.系统按不同功能进行模块化,避免重复造轮子,提升复用率,模块间独立解耦,模块化层度高且可自定义灵活扩展模块,系统功能扩展、升级维护方便,方便不同部门间开发协作。
3.产品开发包与操作系统和硬件解耦分离,产品应用可适配不同操作系统、硬件平台,对于自定义的硬件设备可进行灵活适配,提高产品开发平台扩展性,方便跨平台复用和移植。
4.设备间不再孤立,可利用分布式服务进行便捷的互联互通,实现万物互联的目的,对多个设备上的应用服务进行组合,从而构建更复杂的应用。
附图说明
图1是本发明系统的一种架构示意图;
图2是本发明方法的一种流程示意图;
图3是本发明方法中根据服务分布式状态调用服务的流程示意图;
图4是本发明方法中平台抽象层接口调用BSP层接口的流程示意图。
具体实施方式
下面通过实施例,并结合附图,对本发明的技术方案作进一步具体的说明。
实施例:
本实施例一种产品开发包与操作系统和硬件分离的系统,如图1所示,包括:
应用开发的产品开发包,设备开发的平台抽象层和BSP层,
产品开发包包含行业解决方案、产品通用功能库和应用服务层。可根据用户要求的产品类型、物模型定义、硬件需求生成适配的开发包,以实现降低开发成本和难度,提高产品的开发效率。具体的,
行业解决方案,为提供面向某行业产品标准功能的完整实现方案,用户可零代码开发或低代码开发产品。包括但不限于电工、照明、家电厨卫、户外出行、节能能源、智能锁、运动健康等行业领域;将产品通用功能库中的功能函数组合在一起调用,形成不同的产品,使得用户开箱即用,实现零代码开发。若用户想添加新功能,只需将产品通用功能库中的功能函数添加到程序调度器中,实现低代码扩展新功能。
产品通用功能库,提炼各类产品通用功能,将产品功能分类抽象并模块化,制作形成一系列功能函数库,包括但不限于开关阀控、计量功能、通信功能、安全防盗等;用户只需了解有哪些可用的功能函数,不需要研究具体的复杂实现原理,降低产品开发难度。产品功能函数内部通过服务调用的形式调用一个或多个服务能力实现。
应用服务层,将常用程序功能封装成独立的服务,这些服务支撑实现一个个具体的产品功能,分离解耦应用开发和设备开发。服务包括但不限于电源管理服务、网络管理服务、位置服务、文件系统服务、事件管理服务、OTA服务、安全服务、参数管理服务、IoT云服务等。当用户需要开发某类产品功能时,可直接选择调用相应的应用服务能力,应用服务能力内部调用底层操作系统及硬件来具体实现功能,用户无需关心具体复杂的实现过程。
具体的,服务对应一个服务对象实例,通过service_id唯一标识,一个服务具备多种能力,用ability_id标识,服务能力的控制参数为ability_params。服务能力包括服务处理函数,由用户开发注册,含多个能力处理分支,每个分支为某个服务能力具体的复杂实现。功能函数发起服务调用,使用服务对象实例、ability_id、ability_params作为形参,通过服务分发机制分配一个线程,执行对应的服务处理函数,调用服务提供的能力。
服务具备分布式功能,设备不仅可访问本地服务,也可以访问其他设备发布的服务;具体实现为在同一局域网的物联网设备之间,搭建一条虚拟的设备总线,单个物联网设备可以分解为多个应用服务连接在设备总线上,由此呈现给用户一个大的虚拟设备,单个设备可以基于设备总线调用其他设备的应用服务,甚至可以对多个设备上的应用服务进行组合,实现跨设备调用,从而构建更复杂的应用,实现更复杂的功能,互联互通便捷,达到分布式应用服务的目的。
物联网设备根据功能分为两类:服务发布端,服务发现端,一个设备运行同时具备服务发布和服务发现功能。
服务发布:设备将自身具备的同类功能提炼为服务,可用service_id唯一标识。每种服务提供多种能力,可用ability_id唯一标识。每个能力对应一个能力实现函数,可用ability_func标识。设备可将自己具备多种能力的服务发布到设备总线上。比如智能灯具可以提炼为灯控服务,具备打开灯、关闭灯、调节灯光强度、调节灯光色彩等多种能力。
服务发现:设备可以从设备总线上搜索其它设备发布的服务,并根据自身需要调用其它设备中服务的能力。
并且服务支持事件机制,可发布和订阅服务事件;服务支持同步和异步方式调用服务;且服务可由用户自定义。
基于上述产品开发包的分层设定,开发产品时,获取相应产品功能的行业解决方案,行业解决方案组合调用功能函数形成产品,功能函数通过调用服务实现。
平台抽象层,包括OS内核抽象层和硬件设备抽象层,其中硬件设备抽象层包括IoT模块抽象和控制器抽象,OS内核抽象层对操作系统功能进行抽象。通过将操作系统和硬件设备进行抽象,对上层应用开发提供统一接口,形成上层应用与BSP层的访问桥梁,达到产品开发包与操作系统和硬件分离的效果。服务通过平台抽象层提供的接口访问BSP层底层系统和硬件。
IoT模块抽象,指主控芯片周围外接设备,如传感器模块、通信模块、存储模块、输入和显示类模块、电源管理模块等。对IoT模块进行抽象,建立设备模型,提供访问设备的统一抽象接口;例如,所有LED指示灯的功能都包括普通亮灭、颜色控制、周期闪烁控制等,将这些通用功能接口抽象出来形成模块化的LED设备,避免重复造轮子,不同的LED硬件使用相同接口,屏蔽底层实际硬件差异。常见的IoT抽象模型包括但不限于网络设备、sensor类设备、LED设备、Light设备、输入设备、Display设备等设备模型。
控制器抽象,对不同架构控制器外设接口和内部资源进行抽象,生成控制器设备,提供访问设备的统一抽象接口,以屏蔽不同芯片原厂平台控制器使用上的差异。外设接口通常包括但不限于GPIO、UART、SPI、IIC、PWM、CAN、USB等,内部资源通常包括但不限于FLASH、Timer、RTC、WATCH、中断管理。
OS内核抽象层,对操作系统内核接口进行抽象,以适配不同原厂平台的操作系统内核。适配Linux、RTOS等类型操作系统提供一个统一的系统接口,包括但不限于消息队列、信号量、互斥量等常用功能,建立产品开发包与底层操作系统之间的访问桥梁。
BSP层,包括第三方OS和芯片原厂驱动库,通过平台抽象层与产品开发包分离,当用户开发时需要使用不同的操作系统以及芯片平台时,可以进行更换适配但不需要更改上层应用程序,避免出现重复开发资源浪费的问题,实现跨平台。
第三方OS,为主流的linux、RTOS内核。
芯片原厂驱动库,主控芯片原厂提供的开发库,对主控芯片上的资源进行了封装,用户不需要深入理解寄存器和汇编相关内容即可访问主控的外设和内部资源,如stm32芯片的HAL库。
本实施例系统分层架构将产品开发分成应用开发和设备开发,应用开发只需关注业务逻辑开发,开发应用不需要关注底层实现,只需了解有哪些接口,设备开发开发硬件和系统相关的底层功能。系统软件按照功能不同划分为多个层次,分层从上到下依次为产品开发包、平台抽象层、BSP层,各层之间通过定义的抽象接口进行通信和协作。
采用产品开发包进行组合式应用开发,简化开发流程,让产品开发者进一步降低开发成本和难度,提升产品的开发效率。产品开发包通过应用服务层实现应用开发与操作系统和硬件的分离,集成通用产品功能库和行业解决方案,实现了应用的低代码开发能力,平台抽象层使得设备抽象与BSP层分离,起到了屏蔽硬件差异的作用。
本实施例还包括一种产品开发包与操作系统和硬件分离的方法,采用上述的系统进行实施,包括:
将系统分离成包括产品开发包的应用开发,以及包括平台抽象层和BSP层的设备开发;
将产品开发包分层为行业解决方案、产品通用功能库和应用服务层,所述产品通用功能库将产品功能抽象模块化形成的功能函数,所述应用服务层将程序功能封装形成的服务,行业解决方案组合调用功能函数形成产品,功能函数通过调用服务实现;
平台抽象层将操作系统和硬件设备进行抽象,为应用开发和BSP层提供统一接口,服务通过平台抽象层提供的接口访问BSP层底层系统和硬件。
具体实施过程,如图2所示,包括以下步骤:
S1.进行初始化,包括设备进行OS初始化、设备驱动初始化、应用服务初始化和产品功能库初始化。
设备驱动初始化,完成设备驱动框架底层依赖的注册。
应用服务初始化,注册底层依赖接口,注册服务能力处理函数,创建线程池,创建服务的实例函数,将服务绑定到线程池。
产品功能库各类APP初始化,加载依赖的服务,获取服务的实例对象。
初始化完成后,程序正常运行,可选择订阅服务事件,订阅当前或其他服务的事件,注册事件回调函数。当订阅事件发生时,调用注册的事件回调函数。
S2.当有外部触发或检测到触发状态,触发产品功能时,调用产品功能库中对应的功能函数app_xxxfunc()。产品通用功能库功能函数通过应用服务提供的能力实现,服务屏蔽了产品功能的复杂实现逻辑,对上提供服务调用这种简单的接口,产品功能库的功能函数app_xxxfunc()通过执行简单的服务调用,以类似发送命令的方式,访问服务提供的能力。
S3.调用服务调用函数service_call(),通过形参传入服务对象实例、ability_id、ability_params、输出回调函数,访问服务提供的能力。服务的执行结果可通过输出回调函数获取。
S4.进行服务分发,对服务分配线程,执行服务处理函数。进入服务分发环节,先向服务绑定的线程池发送消息,若是同步调用,接下来阻塞等待输出信号,若是异步调用,直接返回退出。线程池收到消息后,分配一个空闲线程,执行服务注册的服务处理函数。
S5. 如图3所示,进行服务分布式状态判断,判断为本地调用服务还是远程调用服务,若是本地调用服务,采用如下步骤:
S501.执行服务处理函数的能力分支。服务处理函数的能力分支是产品功能的具体复杂实现,每一个服务能力对应一个处理分支,根据传入的ability_id区分执行。
S502.服务能力调用平台抽象层接口。调用平台抽象层接口包括OS内核抽象层接口和设备抽象层接口。
S503.平台抽象层接口调用BSP层接口。OS内核抽象层接口底层是调用第三方OS内核接口,设备抽象层接口底层是调用芯片原厂驱动库接口。
若是远程调用服务,采用如下步骤:
S511.发现端网络通信:发送服务调用请求。
S512.发布端收到服务调用请求,解析出所需调用服务。
S513.发布端从本地服务列表中找到该服务对象实例。
S514.采用本地调用步骤,调用服务。
S515.发布端网络通信:发送服务调用响应。
S516.发现端收到服务调用响应。
S6.服务处理函数执行结束,返回输出结果。调用输出回调函数,形参传入服务输出结果。
进行调用机制判断,即判断同步调用还是异步调用,若是同步调用方式,发送输出信号,之前等待输出信号的地方退出阻塞。
以下采用实例对上述方法进行说明。
BSP层可以使用不同的OS内核和主控芯片,当更换OS内核或主控芯片时,只需完成OS内核抽象层或设备抽象层适配,上层产品应用程序不需要改动,实现跨平台复用。BSP层假设使用RT-Thread和主控芯片使用stm32,OS内核抽象层使用CMSIS_RTOS标准接口,产品功能以灯光控制、按键功能为例,方法步骤如下:
S1.上电后,进行初始化,设备依次进行OS初始化、设备驱动初始化、应用服务初始化和产品功能库APP初始化。
OS初始化,调用CMSIS_RTOS的初始化接口osKernelStart(),内部会调用RT-Thread的初始化函数,完成OS系统环境初始化。
设备驱动初始化,灯光控制会用到Light设备,按键功能会用到Input类设备,IoT模块抽象模块将Light设备、Input类设备的底层操作函数注册到设备驱动框架中,并创建Light设备、Input类设备对象实例存放到设备链表里。MCU抽象层将stm32 HAL库的GPIO、UART、SPI、IIC等常用外设驱动作为设备注册到设备驱动框架中,并创建设备对象实例存放到设备链表里。设备驱动框架对外提供device_open()、device_close()、device_read()、device_write()、device_ctrl()等device标准接口以及其它device扩展接口来访问控制设备。
应用服务初始化,灯控服务会注册底层依赖的Light设备设备接口,输入管理服务会注册底层依赖的Input设备接口。接着注册服务能力处理函数,创建线程池,创建服务的实例对象添加到服务链表,将服务绑定到线程池。
产品功能库APP初始化,灯光控制会用到灯控服务,按键功能会用到输入管理服务。APP初始化函数可通过service_id,从服务链表中获取灯控服务、输入管理服务的实例对象。
初始化完成后,程序正常运行。可通过输入管理服务的实例对象订阅输入管理服务的按键事件,注册按键事件回调函数。
输入管理服务将事件回调函数,添加到事件的订阅链表里。当按键事件发生时,遍历事件订阅链表,依次取出事件回调函数执行。
S2.当收到按键输入事件或下行控制命令,触发产品灯控功能时,调用产品功能库中的灯控功能函数。
产品灯控功能参考如下:常见功能有开关控制、亮度控制、颜色控制等,用户可自定义增加。
S3.产品灯控功能函数内部进一步调用服务调用函数service_call(),通过形参传入灯控服务对象实例、ability_id、ability_params、输出回调函数,去访问灯控服务提供的能力。灯控服务的执行结果可通过输出回调函数获取。
灯控服务提供的服务能力,参考如下:开关控制能力、亮度控制能力、颜色控制能力,用户可自定义增加。
S4. 发起灯控服务调用后,进入服务分发环节。可使用OS的消息队列机制,向服务绑定的线程池发送一个消息。若是同步调用,接下来可通过二值信号量阻塞等待输出信号,若是异步调用则直接返回退出service_call。
收到消息后,线程池中存在阻塞等待消息队列的线程,会有一个线程因获得消息退出阻塞,从消息中获取灯控服务实例对象,通过灯控服务实例对象获得之前注册的灯控服务处理函数并执行。
灯控服务处理函数:包含了灯控服务能力的具体复杂实现,可使用C语言switch语法,通过传入的灯控功能ability_id来分开处理开关控制能力、亮度控制能力、颜色控制能力。
S5. 进行服务分布式状态判断,若是本地调用服务,采用如下步骤:
S501. 执行灯控服务处理函数的能力分支。
ability_id等于开关控制,则执行开关控制能力分支。ability_id等于亮度控制,则执行亮度控制能力分支。ability_id等于颜色控制,则执行颜色控制能力分支。
S502. 灯控服务能力的具体实现调用平台抽象层接口,包括OS内核抽象层接口和设备抽象层接口。
灯控服务能力具体实现:调用Light设备的device标准接口实现控制实际的灯具。
通过device_open()函数初始化Light设备硬件,形参传入Light设备名称,返回Light设备对象实例。
通过device_write()函数控制灯开关,形参传入Light设备对象实例,写入缓存,写入大小,其中写入缓存第一个字节表示灯的id,第二个字节表示开关,即1表示开,0表示关。
通过device_ctrl函数控制灯具的亮度和色彩,形参传入Light设备对象实例,命令控制字cmd和控制参数arg,cmd用来指示控制灯亮度还是色彩,arg传入控制亮度或色彩的参数。
S503. 平台抽象层接口调用BSP层接口。OS内核抽象层接口底层是调用第三方OS内核接口,设备抽象层接口底层是调用芯片原厂驱动库接口。
Light设备调用BSP层接口:
device_open()函数,内部会调用注册的light_open(),初始化Light设备的stm32控制引脚。
device_write()函数,内部会调用注册的light_write(),获取写入缓存的内容,得知要开关那个灯。
device_ctrl()函数,内部会调用注册的light_ctrl(),获取传入的cmd和arg,得知要怎么控制灯。
灯具的控制引脚主要是GPIO和PWM。light_open()、light_write()、light_ctrl()函数先通过device标准接口调用MCU抽象层的PIN和PWM设备接口,PIN和PWM设备底层调用stm32 HAL库中的GPIO和PWM驱动库。
若是远程调用服务,采用如下步骤:
S511.服务发现端网络通信:通过RPC通信接口,发送服务调用请求。
S512.服务发布端通过RPC接收线程收到服务调用请求,解析出调用哪个服务。
S513.服务发布端从本地服务列表中找到灯控服务对象实例。
S514.按照本地调用步骤,调用灯控服务的服务处理函数。
S515.服务发布端网络通信:通过RPC通信接口,发送服务调用响应。
S516.服务发现端通过RPC接收线程收到服务调用响应。
S6. 灯控服务处理函数执行结束,返回输出结果。调用输出回调函数,形参传入服务输出结果。
进行调用机制判断,即判断同步调用还是异步调用,若是同步调用方式,发送二值信号量作为输出信号,之前等待输出信号的地方退出阻塞。
如图4所示,调度服务过程中平台抽象层接口调用BSP层接口,具体包括以下步骤:
a.定义设备的抽象层接口和BSP层接口,抽象层接口与BSP层接口类型对应;
设备抽象层基于底层硬件为应用开发提供抽象的驱动访问接口,实现对硬件设备的控制和管理,屏蔽硬件设备的差异性。设备抽象层采用桥接设计模式,用于将抽象接口和它的实现接口分离,使得两者可以独立的变化。其中抽象接口对应设备抽象层接口,实现接口对应BSP层接口。具体的对接口进行定义,包括
1)定义设备的抽象层接口,假设使用device_ops结构体封装,包含不局限于以下接口:device_open、device_read、device_write、device_ctrl、device_close,接口对应实例函数。
其中:
device_open:执行设备初始化操作;
device_read:执行获取设备数据或状态信息的操作,使用缓存buffer接收数据;
device_write:执行修改设备数据或改变状态、属性的操作,使用缓存buffer传入数据;
device_ctrl:执行设备命令调用,改变设备状态、属性的操作,使用cmd和args传入控制命令;
device_close:执行设备去初始化操作;
参考伪代码实施例如下:
struct device_ops
{
int (*open) (device_t *dev, int oflag);
int (*close) (device_t *dev);
int (*read) (device_t *dev, int pos, void *buffer, int size);
int (*write) (device_t *dev, int pos, const void *buffer, int size);
int (*ctrl) (device_t *dev, int cmd, void *args);
};
2)定义设备的BSP层接口,假设使用bsp_ops结构体封装,包含不局限于以下接口:open、read、write、ctrl、close;BSP层接口包含实例函数和抽象层接口一样。BPS接口的实例函数使用芯片原厂的驱动库来实现,例如stm32芯片的HAL库。
抽象层接口的实例函数中,同类型的实例函数其内部调用BSP层接口里对应同类型的实例函数,例如抽象层接口里的device_open调用BSP层接口里的open,抽象层接口里的device_read调用BSP层接口里的read。
参考伪代码实施例如下:
int device_read(device_t *dev, int pos, void *buffer, int size)
{
//...
dev->bsp_ops->read(dev, pos, buffer, size);
//...
}
3)定义设备结构体device_t来描述设备,设备结构体内至少包含设备名称、抽象接口指针、BSP接口指针、设备链表节点。
其中:
设备名称:唯一标识设备;
设备链表节点:用于将设备添加到设备链表里,统一存放,方便查找设备;
抽象接口指针:指向抽象接口的实例函数,向用户提供设备抽象层的接口;
BSP接口指针:指向BSP层接口的实例函数,里面是用BSP层接口实现的;
用户需要实现设备结构体内BSP层接口实例、抽象层接口实例,创建设备对象实例。
4)定义设备抽象层注册接口device_register(device_t *dev),用于将设备对象实例添加到设备链表里。
5)定义设备抽象层查找接口device_find(char *name),用于从设备链表里获取设备对象实例,后续通过设备对象实例调用设备抽象层接口。
b.对设备和硬件进行初始化;具体包括,
创建设备对象实例,用芯片原厂接口完成BSP层接口内功能;
调用设备注册接口,注册设备,将设备对象实例添加到设备链表里;
调用设备查找接口,根据设备名称,从设备链表里获取设备对象实现;
调用设备抽象层接口的device_open接口,初始化设备;
device_open接口进一步调用BSP层接口里的open接口;
BSP层接口里的open接口调用芯片原厂驱动库,完成硬件初始化。
c.调用设备的抽象层接口,访问控制设备;具体包括:
调用设备抽象层接口的device_read、device_write、device_ctrl接口,去访问控制设备;
d.抽象层接口调用对应同类型的BSP层接口;具体包括:
device_read、device_write、device_ctrl接口内部进一步调用BSP层接口里的read、write、ctrl接口;
e. BSP层接口调用芯片原厂驱动库,完成硬件访问控制。
当设备不再使用时,调用设备抽象层接口的device_close接口,device_close接口内部调用BSP层接口的close接口,最终调用芯片原厂驱动库,完成硬件去初始化。
以下采用实例对平台抽象层接口调用BSP层接口的过程进行说明,以访问Light设备为例,主控芯片使用stm32,其过程包括:
a.定义设备的抽象层接口和BSP层接口。
b.对设备和硬件进行初始化。
b1.创建设备对象实例light_dev,用芯片原厂接口完成BSP层接口内的功能。
BSP层接口的open实例函数light_open(),实现灯的硬件初始化,使用stm32 HAL库的HAL_GPIO_Init()将开关引脚初始化为GPIO模式,使用HAL库HAL_TIM_PWM_Init()函数将亮度控控制和颜色控制引脚初始化为PWM模式;
BSP层接口的close实例函数light_close(),实现灯的硬件去初始化,使用stm32HAL库的HAL_GPIO_DeInit()完成GPIO引脚去初始化,使用stm32 HAL库的HAL_TIM_PWM_DeInit()完成PWM引脚去初始化;
BSP层接口的write实例函数light_write(),实现灯的开关功能,使用stm32 HAL库的HAL_GPIO_WritePin()实现引脚电平高低设置;
BSP层接口的ctrl实例函数light_ctrl(),实现灯的亮度控控制和颜色控制,使用stm32 HAL库的HAL_TIM_PWM_SetDutyCycle()完成PWM波形设置。
b2.调用设备注册接口device_register(&light_dev),注册设备,将Light设备对象实例light_dev添加到设备链表;
b3.调用设备查找接口device_find("light"),从设备链表里获取Light设备对象实例light_dev,作为后续设备访问的传入形参;
b4.调用Light设备对象实例light_dev的抽象层接口的device_open(&light_dev,OFLAG_RDWR )接口,初始化Light设备,OFLAG_RDWR表示可读可写;
b5. device_open()接口进一步调用BSP层接口里的light_open()接口;
b6. light_open()接口调用stm32 HAL驱动库,完成灯硬件初始化。
c.访问控制Light设备
灯的开关功能,调用device_write(&light_dev,NULL,buffer,2),写入缓存第一个字节表示灯的id,第二个字节表示开关,即1表示开,0表示关;
灯的亮度控制调用device_ctrl(&light_dev,LED_LUMINANCE,val
ue),LED_LUMINANCE表示设置灯的亮度,value指定具体亮度值;
灯的颜色控制调用device_ctrl(&light_dev,LED_COLOR,value),LED_COLOR表示设置灯的颜色,value指定具体RGB颜色分量值。
d. Light设备对象实例light_dev的device_write()/device_ctrl()接口内部进一步会调用BSP层接口里的light_write()/light_ctrl();
e. light_write()/light_ctrl()调用stm32 HAL驱动库,真正完成灯的访问控制;
当Light设备不再使用时,调用Light设备对象实例light_dev的抽象层接口的device_close(&light_dev)接口,内部进一步调用BSP层接口的light_close(),最终调用调用stm32 HAL驱动库,完成硬件去初始化。
本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代,但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。

Claims (8)

1.一种产品开发包与操作系统和硬件分离的方法,其特征在于,包括:
将系统分离成包括产品开发包的应用开发,以及包括平台抽象层和BSP层的设备开发;
将产品开发包分层为行业解决方案,产品通用功能库和应用服务层,所述产品通用功能库将产品功能抽象模块化形成功能函数,所述应用服务层将程序功能封装形成服务,行业解决方案组合调用功能函数形成产品,功能函数通过调用服务实现;设定服务对应一个服务对象实例,服务包括多种能力,服务能力对应设置服务处理函数,功能函数发起服务调用,执行对应的服务处理函数,调用服务提供的能力;
所述平台抽象层将操作系统和硬件设备进行抽象,为应用开发和BSP层提供统一接口,所述服务通过平台抽象层提供的接口访问BSP层底层系统和硬件。
2.根据权利要求1所述的一种产品开发包与操作系统和硬件分离的方法,其特征是所述的行业解决方案组合调用功能函数形成产品,功能函数通过调用服务实现,具体包括:
进行初始化,包括设备进行OS初始化,设备驱动初始化,应用服务初始化和产品功能库初始化;
当有外部触发或检测到触发状态,触发产品功能时,调用产品通用功能库中对应的功能函数;
调用服务调用函数,访问服务提供的能力;
进行服务分发,对服务分配线程,执行服务处理函数。
3.根据权利要求2所述的一种产品开发包与操作系统和硬件分离的方法,其特征是所述的服务通过平台抽象层提供的接口访问BSP层底层系统和硬件,具体包括:
进行服务分布式状态判断,进行本地调用服务或远程调用服务;
调用服务包括:
执行服务处理函数的能力分支,
服务能力调用平台抽象层接口,
平台抽象层接口调用BSP层接口;
服务处理函数执行结束,进行调用机制判断,输出结果信号。
4.根据权利要求3所述的一种产品开发包与操作系统和硬件分离的方法,其特征是所述步骤的平台抽象层接口调用BSP层接口,具体包括:
a.定义设备的抽象层接口和BSP层接口,抽象层接口与BSP层接口类型对应;
b.对设备和硬件进行初始化;
c.调用设备的抽象层接口,访问控制设备;
d.抽象层接口调用对应同类型的BSP层接口;
e. BSP层接口调用芯片原厂驱动库,完成硬件访问控制。
5.一种产品开发包与操作系统和硬件分离的系统,用于实施权利要求1-4任一项中所述的方法,其特征在于,包括:应用开发的产品开发包,设备开发的平台抽象层和BSP层,
产品开发包,包含行业解决方案,产品通用功能库和应用服务层,产品通用功能库包括将产品功能抽象模块化形成的功能函数,行业解决方案组合调用功能函数形成产品,应用服务层包括程序功能封装形成的服务,功能函数通过调用服务实现;所述服务对应一个服务对象实例,具备多种能力,服务能力包括服务处理函数,功能函数发起服务调用,执行对应的服务处理函数,调用服务提供的能力;
平台抽象层,将操作系统和硬件设备进行抽象,为应用开发和BSP层提供统一接口,服务通过平台抽象层提供的接口访问BSP层底层系统和硬件。
6.根据权利要求5所述的一种产品开发包与操作系统和硬件分离的系统,其特征是所述服务通过设备形式连接在设备总线上,设备基于设备总线调用其他设备的服务。
7.根据权利要求6所述的一种产品开发包与操作系统和硬件分离的系统,其特征是所述平台抽象层包括OS内核抽象层和硬件设备抽象层,
OS内核抽象层,对操作系统内核接口进行抽象,以适配不同操作系统内核;
硬件设备抽象层,包括IoT模块抽象和控制器抽象,其中,
IoT模块抽象,对IoT模块进行抽象,建立设备模型,提供访问设备的统一抽象接口;
控制器抽象,对不同架构控制器外设接口和内部资源进行抽象,生成控制器设备,提供访问设备的统一抽象接口。
8.根据权利要求7所述的一种产品开发包与操作系统和硬件分离的系统,其特征是所述BSP层包括第三方OS和芯片原厂驱动库。
CN202410023629.1A 2024-01-08 2024-01-08 一种产品开发包与操作系统和硬件分离的方法及系统 Active CN117519783B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410023629.1A CN117519783B (zh) 2024-01-08 2024-01-08 一种产品开发包与操作系统和硬件分离的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410023629.1A CN117519783B (zh) 2024-01-08 2024-01-08 一种产品开发包与操作系统和硬件分离的方法及系统

Publications (2)

Publication Number Publication Date
CN117519783A CN117519783A (zh) 2024-02-06
CN117519783B true CN117519783B (zh) 2024-04-26

Family

ID=89742444

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410023629.1A Active CN117519783B (zh) 2024-01-08 2024-01-08 一种产品开发包与操作系统和硬件分离的方法及系统

Country Status (1)

Country Link
CN (1) CN117519783B (zh)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004028125A1 (en) * 2002-09-23 2004-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Middleware application message/event model
CN109508202A (zh) * 2018-09-27 2019-03-22 华东计算技术研究所(中国电子科技集团公司第三十二研究所) 嵌入式操作系统的驱动开发系统、方法及介质
CN110780858A (zh) * 2019-10-28 2020-02-11 天津津航计算技术研究所 一种基于嵌入式操作系统的软件分层架构
CN111309291A (zh) * 2020-01-19 2020-06-19 北京航空航天大学 一种模块化嵌入式软件架构及其定制方法、定制系统
CN113220276A (zh) * 2021-05-28 2021-08-06 杭州国芯科技股份有限公司 一种跨平台的嵌入式软件架构系统
CN114520754A (zh) * 2022-04-21 2022-05-20 石家庄科林电气股份有限公司 一种配电网边缘网关的软件架构方法及网关终端
WO2022126930A1 (zh) * 2020-12-17 2022-06-23 威胜集团有限公司 一种嵌入式设备驱动系统及方法
CN116382641A (zh) * 2023-01-04 2023-07-04 湖北三江航天红峰控制有限公司 一种分层的嵌入式软件架构系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004028125A1 (en) * 2002-09-23 2004-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Middleware application message/event model
CN109508202A (zh) * 2018-09-27 2019-03-22 华东计算技术研究所(中国电子科技集团公司第三十二研究所) 嵌入式操作系统的驱动开发系统、方法及介质
CN110780858A (zh) * 2019-10-28 2020-02-11 天津津航计算技术研究所 一种基于嵌入式操作系统的软件分层架构
CN111309291A (zh) * 2020-01-19 2020-06-19 北京航空航天大学 一种模块化嵌入式软件架构及其定制方法、定制系统
WO2022126930A1 (zh) * 2020-12-17 2022-06-23 威胜集团有限公司 一种嵌入式设备驱动系统及方法
CN113220276A (zh) * 2021-05-28 2021-08-06 杭州国芯科技股份有限公司 一种跨平台的嵌入式软件架构系统
CN114520754A (zh) * 2022-04-21 2022-05-20 石家庄科林电气股份有限公司 一种配电网边缘网关的软件架构方法及网关终端
CN116382641A (zh) * 2023-01-04 2023-07-04 湖北三江航天红峰控制有限公司 一种分层的嵌入式软件架构系统

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Xinyu Wang Etc..BSENet: A Data-Driven Spatio-Temporal Representation Learning for Base Station Embedding.IEEE Access ( Volume: 8).2020,全文. *
刘伟 等.MCU的嵌入式设备通用软件平台研究.新器件新技术.2023,全文. *
赵兴祥 等.一种低耦合可移植的嵌入式主控软件架构设计.微处理机.2020,(第6期),全文. *
马若飞 ; 杨柳 ; 雷连发 ; .跨平台模块化嵌入式多任务软件框架研究.火控雷达技术.2017,(04),全文. *

Also Published As

Publication number Publication date
CN117519783A (zh) 2024-02-06

Similar Documents

Publication Publication Date Title
US11573844B2 (en) Event-driven programming model based on asynchronous, massively parallel dataflow processes for highly-scalable distributed applications
McAffer Meta-level programming with CodA
JPH10240509A (ja) ソフトウェアアプリケーションを生成する方法、生成装置、プログラムモジュールおよびデータ処理装置
US6389483B1 (en) System and method for reducing coupling between modules in a telecommunications environment
US20030056205A1 (en) System of reusable software parts for event flow synchronization and desynchronization, and methods of use
US20120072480A1 (en) Elastic management framework
Karaorman et al. Introducing concurrency to a sequential language
CN111309291B (zh) 一种模块化嵌入式软件架构及其定制方法、定制系统
Yoong et al. IEC 61499 in a Nutshell
CN113687913A (zh) 一种面向边缘计算异构环境的轻量级应用适配方法
JP2004503866A (ja) モジュラーコンピュータシステムおよび関連方法
CN116822135A (zh) 实时仿真平台系统及仿真系统构建方法
US20040015816A1 (en) Coordination synthesis for software systems
WO2024093731A1 (zh) 汽车开放系统架构、数据处理方法及车载设备
CN117519783B (zh) 一种产品开发包与操作系统和硬件分离的方法及系统
Åkerholm et al. A sample of component technologies for embedded systems
Popović et al. Modeling and development of autosar software components
Morel Components for Grid Computing
Elrad et al. A hierarchical and reflective framework for synchronization and scheduling controls
Nickschas et al. CARISMA-A Service-Oriented, Real-Time Organic Middleware Architecture.
Dupire et al. The command dispatcher pattern
Savigni et al. Real-time programming-in-the-large. The case of monitoring and control systems
Kaliski Multi-tenant cloud computing: From cruise liners to container ships
Rotta et al. Software Architecture Fundamentals
Hamri et al. The state event design pattern

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant