16.1嵌入式系统概述
嵌入式系统是为了特定应用而专门构建的计算机系统
16.1.1嵌入式系统发展历程
| 阶段 | 名称 | 核心特点 |
|---|---|---|
| 第一阶段 | 单片微型计算机(SCM) | 硬件为单片机,无操作系统,用汇编语言;功能单一、效率低、存储小、无用户接口 |
| 第二阶段 | 微控制器(MCU) | 以嵌入式微处理器+简单操作系统为主;扩展外围接口,种类多、通用性弱、系统开销小、效率高 |
| 第三阶段 | 片上系统(SoC) | 可运行在多种处理器,兼容性好;操作系统内核小、效率高 |
| 第四阶段 | 基于Internet的嵌入式系统 | 处理器集成网络接口,设备网络化,应用于网络环境 |
| 第五阶段 | 智能化、云技术驱动 | 低能耗、高速度、高集成、高可信、环境适应性强;向微型传感设备与智能服务设备两大方向发展 |
16.1.2嵌入式系统硬件体系结构
嵌入式系统主要由嵌入式微处理器(控制器 (Micro Control Unit,MCU))、 存 储 器 (RAM/ROM)、 内(外)总线逻辑、定时/计数器 (Time)、 看门狗电路、 I/O接口(串口、网络、 U S B 、 J T A G等 ) 和 外 部 设 备 ( U A R T 、 L E D等 ) 等 部 件 组 成

1.嵌入式处理器
| 类型 | 核心特点 | 典型代表 |
|---|---|---|
| MPU 微处理器 | 板载外设多,体积小、可靠性较高;需外接 ROM/RAM | ARM、PowerPC、MIPS、386EX |
| MCU 微控制器 | 单片化,集成处理器+存储器+外设,功耗低、可靠性高 | 51 系列、AVR、PIC、ARM Cortex-M |
| DSP 数字信号处理器 | 哈佛结构,擅长密集算法,运算速度快 | TI TMS320 系列、Freescale DSP56000 |
| GPU 图形处理器 | 并行渲染,分担 CPU 图形运算,3D 加速能力强 | 各类显卡/嵌入式 GPU 核心 |
| SoC 片上系统 | 高集成度,大部分系统功能集成到单芯片 | 手机/物联网主流芯片方案 |
2.存储器
RAM(随机存取存储器,断电丢失)
| 类型 | 特点 | 典型用途 |
|---|---|---|
| DRAM 动态 | 需刷新,成本低,容量大 | 主存 |
| SRAM 静态 | 速度快,无需刷新,成本高 | Cache 高速缓存 |
| SDRAM | 与 CPU 时钟同步 | 通用内存 |
| DDR SDRAM | 双倍速率,主流 | 计算机/嵌入式内存 |
| VRAM/SGRAM/WRAM | 双端口/绘图优化 | 显卡显存 |
ROM(只读存储器,掉电不丢)
| 类型 | 特点 |
|---|---|
| MASK ROM | 掩膜出厂,不可改,成本低 |
| PROM | 一次性可编程 |
| EPROM | 紫外线擦除,可重复编程 |
| EEPROM | 电可擦除,按字节改写 |
| Flash | 块擦除,容量大、速度较快,广泛使用 |
3.总线与接口
总线分类
- 片内总线:CPU 内部元件互联
- 系统总线:连接 CPU、内存、I/O
- 局部总线:少数组件间高速互联
- 通信总线:外部设备/系统间通信
总线结构
星形、树形、环形、总线型、交叉开关型
常见总线标准
PCI、cPCI、I2C、CAN、SCI、IEEE 1394、1553B 等
4.典型硬件模块
| 模块 | 作用 |
|---|---|
| 看门狗 | 程序跑飞/死机时自动复位,保障系统可靠 |
| I/O 接口 | 串行、并行、AD/DA、定时器、中断、DMA 等 |
| 外部设备 | 键盘、鼠标、显示、打印、传感器、JTAG 调试 |
16.1.3嵌入式软件架构概述
GOA 架构主要特点
| 特点 | 核心说明 |
|---|---|
| 可移植性 | 应用可在不同型号、不同机型的开放结构计算机间移植 |
| 可互操作性 | 网络中各开放结构节点可互操作、实现资源共享 |
| 可剪裁性 | 低档机应用可在高档机运行;高档机应用剪裁后可在低档机运行 |
| 易获得性 | 软件环境可从多方获取,不被单一来源控制 |


16.2嵌入式系统软件架构原理与特征
16.2.1两种典型的嵌入式系统架构模式
1.层次化模式架构
为了达到概念一致性,许多系统通过层次化的方法进行搭建。这样做的结果是:位于高层的抽象概念与低层的更加具体的概念之间存在着依赖关系。即:系统所在的域可以被认为是由一组带有语义的概念构成,并且这些概念位于一个特定的抽象层次之中。域中更加抽象的概念是由位于其他层上更为具体的概念实现。
层次化模式架构核心要点
| 项目 | 内容 |
|---|---|
| 设计思想 | 系统存在高层抽象,需由低层概念实现时,采用分层结构 |
| 模式结构 | 包含一个主元素(域包)、接口及约束条件 |
| 封闭型分层 | 只能调用同层或直接下一层,封装性好、移植性强 |
| 开放型分层 | 可调用同层或任意下层,性能更好,但破坏封装、移植性较差 |

2.递归模式架构
递归模式解决的问题是:需要将一个非常复杂的系统进行分解,并且还要确保分解过程是可扩展的,即只要有必要,该分解过程就可以持续下去。这样做的好处是:可以将需求阶段得到的一个非常复杂的用例用逐步求精的方法映射到这种设计架构,并在每步求精细化时,进行系统可靠性和实时性的验证。
递归模式实际上是对系统的抽象:系统中的交互协作可以在不同的层次上进行抽象,只不过每层反映的细节不同而已。
| 方式 | 核心思路 | 适用特点 |
|---|---|---|
| 自顶向下 | 从系统级开始,划分子系统,逐步细化到低层实现 | 贴合需求,不易偏离用例,适合实时/嵌入式系统 |
| 自底向上 | 从领域关键类与关系入手,向上抽象到子系统层级 | 依赖经验复用,从基础组件逐步构建系统 |

16.2.2嵌入式操作系统
嵌入式操作系统的定义及特点
嵌入式操作系统(EOS)特点
| 特点 | 说明 |
|---|---|
| 可剪裁性 | 体系结构开放、可伸缩 |
| 可移植性 | 可在不同处理器、开发板上运行 |
| 强实时性 | 适用于各类控制场景 |
| 强紧凑性 | 代码精炼,适配资源受限环境 |
| 高质量代码 | 可靠,适合安全攸关系统 |
| 强定制性 | 可按目标系统需求专业定制 |
| 标准接口 | 提供统一设备驱动接口 |
| 强稳定性、弱交互性 | 运行后少人工干预,通过系统调用提供服务 |
| 强确定性 | 任务调度与资源管理可确保时限与容量要求 |
| 操作简洁方便 | 提供友好GUI,易用易学 |
| 强硬件适应性 | 移植性好,能充分发挥硬件性能 |
| 可固化性 | 系统与应用可固化在ROM中运行 |
16.2.3嵌入式数据库
嵌入式数据库系统主要特点
| 特点 | 核心说明 |
|---|---|
| 嵌入式 | 可嵌入软件或硬件设备中,是基本特性 |
| 实时性 | 能快速获取资源、及时响应系统请求,需专门设计保障 |
| 移动性 | 适配移动设备,可嵌入的数据库通常移动性好 |
| 伸缩性 | 适应多样化软硬件平台,可按需求灵活配置 |
嵌入式数据库分类(按存储位置)
| 类型 | 核心特点 | 典型应用/说明 |
|---|---|---|
| 内存数据库(MMDB) | 数据常驻内存,无磁盘I/O,执行时间可预测,实时性极强 | 航空、军事、电信、工业控制,适合实时事务 |
| 文件数据库(FDB) | 以文件形式存储,访问简单,安全性低 | DBF、Access、Pocket Access,适配资源受限场景 |
| 网络数据库(NDB) | 依托移动通信,嵌入式设备作为客户端访问远程数据库 | 客户端小巧、无需解析SQL、利于代码重用 |
数据库服务器 vs 嵌入式数据库(对比表)
| 对比项 | 数据库服务器 | 嵌入式数据库 |
|---|---|---|
| 操作主体 | 允许非开发人员操作 | 仅允许应用程序访问控制 |
| 数据与程序 | 数据与程序分离,便于权限控制 | 访问控制由应用程序全权管理 |
| 部署方式 | 独立安装、部署、管理 | 与应用一起发布,无需单独部署 |
| 特点 | 独立运行,集中管理 | 随程序携带,轻量化无独立服务 |
16.2.4嵌入式中间件
1.嵌入式中间件的定义及特点
中间件 (Middleware) 属于可复用软件的范畴。
顾名思义,中间件处于操作系统软件与用户的应用软件的中间,在操作系统、网络和数据库之上,应用软件之下,其作用是为处于上层应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。
嵌入式中间件 (Embedded Middleware) 是在嵌入式系统中处于嵌入式应用和操作系统之间层次的中间软件,其主要作用是对嵌入式应用屏蔽底层操作系统的异构性,常见功能有网络通信、内存管理和数据处理等。
中间件及嵌入式中间件特点与解释
| 类别 | 特点 | 解释 |
|---|---|---|
| 中间件共性特点 | 通用性 | 能够满足大量不同类型应用的通用需求 |
| 异构性 | 可运行在多种硬件平台与多种操作系统之上 | |
| 分布性 | 支持分布式计算,实现跨网络、硬件、OS的透明交互 | |
| 协议规范性 | 遵循并支持各类标准网络与通信协议 | |
| 接口标准化 | 提供标准统一的接口,便于集成与复用 | |
| 嵌入式中间件特有特点 | 网络化 | 支持移动、无线环境下的分布式应用,适配多变网络 |
| 支持流媒体应用 | 适应波动的访问流量与带宽约束,保障流媒体传输 | |
| QoS 质量保障 | 满足分布式嵌入式实时环境下强 QoS 软硬件约束 | |
| 适应性 | 能够适配未来可预见的新增应用需求 |
2.嵌入式中间件的分类
通用中间件分类及说明
| 中间件类型 | 核心作用 |
|---|---|
| 企业服务总线(ESB) | 开放、基于标准的分布式消息中间件,通过XML、Web服务等实现企业应用安全互操作 |
| 事务处理(TP)监控器 | 监控对象间事务处理,保障事务操作正确执行并确保成功 |
| 分布式计算环境(DCE) | 提供一组技术服务,用于创建跨平台的分布式应用程序 |
| 远程过程调用(RPC) | 定义客户端向服务器请求运行某程序的标准通信方式 |
| 对象请求代理(ORB) | 提供接口,使对象可在分布式网络环境中相互通信 |
| 数据库访问中间件 | 支持统一访问不同操作系统、不同应用中的各类数据库 |
| 消息传递中间件 | 实现进程间消息通信,典型如电子邮件系统 |
| 基于XML的中间件 | 利用XML创建结构化信息文档,实现Internet上的数据交换 |
3.嵌入式中间件的一般架构
1.消息中间件
消息中间件是消息传输过程中保存消息的一种容器。
它将消息从它的源中继到它的目标时充当中间人的作用。在消息中间件中,队列的目的是提供路由并保证消息的传递;如果发送消息时接收者不可用,消息队列会保留消息,直到可以成功的传递它为止,当然,消息队列保存消息也是有期限点的

消息中间件具有两个基本特点:
(1)采用异步处理模式:
消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道(主题或队列)上,消息接收者则订阅或是监听该通道。一条消息可能最终转发给一个或多个消息接收者,这些接收者都无须对消息发送者做出同步回应。整个过程是异步的。比如用户消息注册,注册完毕后过段时间发送邮件或者短信。
(2)应用程序和应用程序调用关系为松耦合关系:
发送者和接收者不必了解对方、只需要确认消息,发送者和接收者不必同时在线。比如在线交易系统为了保证数据的最终一致,在支付系统处理完成后会把支付结果放到消息中间件里通过订单系统修改订单支付状态。两个系统通过消息中间件解耦。
消息传递服务模型对比表
| 模型 | 核心特点 | 机制说明 | 关键特性 |
|---|---|---|---|
| 点对点模型(PTP) | 一对一通信 | 消息发送到指定队列,消费者从队列取消息 | 消息持久化,确保可靠传递 |
| 发布-订阅模型(Pub/Sub) | 一对多通信 | 基于主题发布消息,多订阅者可接收 | 发布者与订阅者解耦匿名;非持久订阅需在线,持久订阅可离线重收 |
2.分布式对象中间件
分布式对象中间件是为了解决分布计算和软件复用过程中存在的异构问题而提出的。它的任务是处理分布式对象之间通信,是基于组件的思想,由一组对象来提供系统服务,对象之间能够跨平台通信。
这里的基本组件就是对象,它们提供一组服务,对外给出服务接口,对象之间可以相互调用,服务对象之间不存在客户机和服务器的界限。分布式对象中间件使用了分布式技术,它将网络上的所用资源互相连接起来,对外表现为一个统一的整体,对客户是透明的,不必区分本地操作和远程操作;分布式对象中间件使用了面向对象技术,它通过封装、继承及多态提供了良好的代码重用功能。
分布式对象中间件(ORB 架构)组成
| 组成部分 | 核心作用 |
|---|---|
| 对象请求代理(ORB) | 分布式对象的"软总线",定义接口与语言映射,实现本地/远程对象透明调用与互操作,支持跨进程、跨主机通信 |
| 公共服务 | 提供对象管理标准功能:并发控制、名字服务、事务服务、安全服务、查询服务等 |
| 公共设施 | 面向应用对象的通用服务框架集合 |
| 应用对象 | 实现具体业务功能,通过 IDL 定义接口,基于 ORB 实现相互调用 |

4.嵌入式中间件的主要功能
嵌入式中间件常用功能
| 功能 | 核心作用 |
|---|---|
| 网络通信 | 提供标准通信接口,屏蔽底层OS与硬件差异,提升应用开放性与可移植性 |
| 存储管理 | 提供跨平台、跨介质存储接口,基于嵌入式数据库/文件系统实现数据共享与互操作 |
| 数据处理 | 构建分布式系统框架,实现事务间基本互操作接口功能 |
16.2.5嵌入式系统软件开发环境
1.嵌入式系统软件开发环境的定义及特点
嵌入式系统软件开发环境是可帮助用户开发嵌入式软件的一组工具的集合,这种工具的集合被集成为一体,形成一套交叉平台开发方法 (Cross Platform Development,CPD)。
交叉开发方法是指嵌入式软件在一个通用的平台上开发(称为宿主机),而在另一个嵌入式目标平台上运
行(称为目标机)。嵌入式系统软件开发环境主要能力包括:集成开发、工程管理、编译(汇编)器、批处理文件、构建 (Make)、 配置管理、调试、下载、模拟、版本控制及其他。
嵌入式系统软件开发环境特点
| 特点 | 解释说明 |
|---|---|
| 集成开发环境(IDE) | 包含代码编辑器、编译器、调试器、GUI 等,提供完整程序开发环境 |
| 交叉开发 | 在通用计算机上编辑、编译、链接,再下载到嵌入式目标板运行调试 |
| 开放式体系结构 | 基于标准框架,支持 ANSI C/C++、ELF 等标准,工具无缝衔接,可集成第三方工具 |
| 可扩展性 | 工具接口符合标准,可按需扩充工具能力 |
| 良好可操作性 | 多工具间可自动交换信息,协作顺畅 |
| 可移植性 | 开发工具多采用高级语言实现,便于移植 |
| 可配置性 | 主要工具可按需伸缩,可选择支持库代码规模 |
| 代码实时性 | 支持代码优化,编译器生成高效代码,满足嵌入式实时运行要求 |
| 可维护性 | 工具间松耦合,便于单独升级和维护 |
| 友好用户界面 | 界面简洁清晰,符合操作习惯,易用性强 |
2.嵌入式系统软件开发环境的分类
我们说嵌入式系统是与应用需要紧密结合的,是一种定制性系统,通常,提供嵌入式系统设备的厂家必然提供一套开发工具,以帮助用户开发相应的软件。那么,为其提供的开发工具也是各种各样,没用通用的开发环境之说。这里所说的嵌入式软件开发环境分类只是一种观点。
通常,嵌入式软件开发环境都是随嵌入式系统配套软件提供给用户的。
根据嵌入式系统软件的调试方法的不同,可分为模拟器方法、在线仿真器方法、监控器方法、 J T A G仿真器等。
嵌入式系统调试方法对比表
| 调试方法 | 核心原理 | 特点说明 |
|---|---|---|
| 模拟器方法 | 调试工具与嵌入式软件均在主机运行,软件模拟目标处理器执行 |
纯软件模拟,无需目标硬件,方便前期调试 |
| 在线仿真器(ICE) | 完全仿造目标CPU,通过仿真头连接目标板,主机控制 | 对目标系统完全透明、可控,硬件级仿真 |
| 监控器方法 | 主机通过接口与目标机监控程序通信,下载程序到目标机运行 |
目标机运行监控程序,配合主机调试器实现调试 |
| JTAG仿真器 | 利用目标板JTAG边界扫描接口进行调试 | 基于硬件调试接口,通用性强,广泛用于芯片调试 |
3.嵌入式软件开发环境的一般架构
嵌入式系统软件开发环境是可帮助用户开发嵌入式软件的一组工具的集合,其架构的主要特征离不开"集成"问题,采用什么样的架构框架是决定开发环境优劣主要因素。
Eclipse框架是当前嵌入式系统软件开发环境被普遍公认的一种基础环境框架。目前大多数嵌入式软件开发环境都是建立在 Eclipse 框架之上的层次化架构,具备开放式、构件化、即插即用等特征。

通常,嵌入式软件开发环境按功能可划分为宿主层、基本工具层、应用工具层和驻留层。
嵌入式软件开发环境四层架构
| 层次 | 核心定位 | 主要组成与功能 | 关键接口/特点 |
|---|---|---|---|
| 宿主层 | 开发环境基础支撑平台 | Eclipse(基础框架、插件机制)、JDK(Java 运行与工具)、CDT(C/C++ 支持) | 跨平台,遵循 Eclipse Plugin API、JRE API、OS API |
| 基本工具层 | 交叉开发核心工具集 | 项目管理、代码编辑、交叉编译、系统配置、链接、调试、目标机管理、代码仿真 | 覆盖编码→构建→编译→下载→调试全流程 |
| 应用工具层 | 高级可视化开发工具 | 效能分析(时间/故障/统计)、目标机交互(Shell 命令)、部署维护(批量升级)、第三方工具集成 | 辅助后期运维与性能优化 |
| 驻留层 | 目标机端支撑组件 | 目标机上的代理(Agent)程序,可剪裁 | 与宿主机对接,提供通信、调试、监视、交互能力 |
4.嵌入式系统软件开发环境的主要功能
| 功能模块 | 核心作用 | 关键说明 |
|---|---|---|
| 工程管理 | 统一组织开发资源 | 管理源码、目标码、配置、脚本等;提供项目向导、模板,为其他工具提供入口 |
| 编辑器 | 代码与文件编辑 | 支持文本、C/C++、脚本、XML 等编辑,满足开发编辑需求 |
| 构建管理 | 自动化批量编译 | 基于 Makefile 规则,对多目录多类型文件智能编译、顺序控制 |
| 编译/汇编器 | 生成目标板可执行代码 | 基于 GCC,将 C/C++/汇编翻译成嵌入式二进制文件 |
| 配置功能 | 系统定制化裁剪 | 根据硬件与需求灵活配置,适应不同嵌入式场景 |
| 调试器 | 源码级/汇编级调试 | 基于 GDB,支持断点、单步、运行控制、查询修改等调试操作 |
| 目标机管理 | 宿主机与目标机通信 | 管理多目标机连接,支持多种传输模式,基于 TCF/DSF 架构 |
| 仿真器 | 软硬件协同开发 | 支持嵌入式软件与硬件并行设计、验证 |
5.典型嵌入式开发环境
| 开发环境 | 核心特点 | 编译器 | 主要优势 |
|---|---|---|---|
| GCC 开源工具环境 | 通用开源交叉编译环境,支持多语言多平台 | GCC、AS、LD、AR 等 | 支持语言多、可移植性强、配置丰富、代码高效可靠 |
| Workbench | 基于 Eclipse,面向 VxWorks,覆盖全开发周期 | Diab(高效安全)+ GCC | 调试能力强、可定制、适合复杂目标系统 |
| MULTI | 高端商用 IDE,支持 INTEGRITY/嵌入式 Linux | GreenHills 优化编译器 | 代码质量高、执行更快更小、追踪回溯强、测试完备、通过高等级认证 |
16.3嵌入式系统软件架构设计方法
16.3.1基于架构的软件设计开发方法的应用
在嵌入式系统中,其设计通常采用了自顶向下的设计方法,基于架构的软件设计 (ABSD) 可适应于嵌入式系统的软件设计方法
基于架构的软件设计 (Architecture-Based Software Design,ABSD) 方法强调由业务、质量和功能需求的组合驱动软件架构设计。 ABSD是一个自顶向下,递归细化的软件开发方法,它以系统功能的分解为基础,通过选择架构风格实现质量和业务需求,并强调在架构设计过程中使用软件架构模板。 ABSD方法是递归的,并不是说需求抽取和分析活动可以终止,而是应该与设计活动并行。设计活动可以从项目总体功能框架明确后就开始,可以逐步迭代、逐步完善的进行,不管设计是否完成,架构总是清晰的,有利于降低架构设计的随意性。
16.3.2属性驱动的软件设计方法
属性驱动的软件设计 (Attribute-Driven Design,ADD) 是把一组质量属性场景作为输入,利用对质量属性实现与架构设计之间的关系的了解(如体系结构风格、质量战术等)对软件架构进行设计的一种方法。
A D D 是一种定义软件体系结构的方法,该方法将模块分解过程建立在软件必须满足的质量属性之上。它是一个递归的分解过程,其中在每个阶段都选择体系结构模式和战术来满足一组质量属性场景,然后对功能进行分配,
1.ADD 开发方法的质量属性
质量属性(嵌入式重点)
| 质量属性 | 说明 |
|---|---|
| 可靠性 | 系统在规定条件下和时间内,完成规定功能的能力 |
| 安全性 | 避免系统故障造成人身、财产、环境危害的能力 |
| 可用性 | 系统正常可用的时间比例,出现故障可快速恢复 |
| 可修改性 | 系统易于修改、扩展、裁剪而不引入新问题 |
| 性能 | 响应时间、吞吐量、资源占用等效率指标 |
| 可测试性 | 便于设计测试用例、定位缺陷的程度 |
| 易用性 | 用户学习、操作、理解系统的难易程度 |
| 可维护性 | 系统故障修复、优化升级的便捷程度 |
质量场景构成(6要素)
| 组成部分 | 含义 |
|---|---|
| 刺激源 | 产生刺激的实体(人、系统、外部设备等) |
| 刺激 | 到达系统并需要处理的事件/问题 |
| 环境 | 刺激发生时系统所处状态与条件 |
| 制品 | 被影响的系统组件(处理器、进程、存储等) |
| 响应 | 系统收到刺激后采取的处理动作 |
| 响应度量 | 可量化衡量响应效果的指标 |
嵌入式系统可用性场景示例
| 场景组成 | 典型取值 |
|---|---|
| 刺激源 | 系统内部、外部 |
| 刺激 | 未响应、崩溃、超时、结果不正确 |
| 制品 | 处理器、信道、持久存储、进程 |
| 响应 | 记录故障、通知相关方、限制事件源、临时降级/不可用 |
| 响应度量 | 可用时长、修复时间、降级运行时长、不可用间隔 |
2.ADD开发过程
采 用 A D D 方 法 进 行 软 件 开 发 时 , 需 要 经 历 评 审 、 选 择 驱 动 因 子 、 选 择 系 统 元 素 、 选 择 设计概念、实体化元素和定义接口、草拟视图和分析评价等七个阶段
嵌入式系统架构设计七步流程
| 步骤 | 核心工作 | 关键内容 |
|---|---|---|
| 步骤一:评审输入 | 校验设计输入有效性 | 确认设计目的、质量属性、功能、约束等驱动因子合理可用;既有架构输入需评估合理性 |
| 步骤二:建立迭代目标 | 按开发模型确定设计回合 | 迭代模型:分回合做架构设计;瀑布模型:一次性完成全套设计;每个迭代聚焦一个驱动因子目标 |
| 步骤三:选择系统元素细化 | 选取并拆解架构组件 | 选择模块/子系统等元素,进行细粒度分解、粗粒度组合或对已有元素进一步细化 |
| 步骤四:选择设计概念 | 选用架构模式与方案 | 从结构模式、分层、域对象设计、接口分区、高并发设计等中选取合适设计概念 |
| 步骤五:实例化元素与定义接口 | 落地架构并分配职责 | 实例化架构元素(如分层),为各元素分配职责,定义元素间交互接口 |
| 步骤六:草拟视图并记录决策 | 固化设计成果 | 以图文形式记录架构视图与设计决策,供后续迭代评审与细化 |
| 步骤七:分析设计与评审目标 | 评估是否达成迭代目标 | 评审当前设计是否满足驱动因子;通过风险评估判断是否需要新一轮迭代;确保关键需求优先满足 |

16.3.3实时系统设计方法
实时系统设计方法 (Design Approach for Real-Time System,DARTS) 常被应用于嵌入式系统的软件设计中
D A R T S方法主要是将实时系统分解为多个并发任务,并定义这些任务之间的接口。该方法起源于实时系统的实时结构化分析和设计方法 (Real-Time Structuring Analysis and Design,RTSAD)。RTSAD 在分析阶段使用实时结构化分析 (RTSA) 方法,设计阶段使用实时结构化设计 (RTSD) 方法,但是这个方法没有考虑实时系统是由一些并发任务组成的这个特点。针对实时系统的这个特点, D A R T S方法提供了一些分解规则和一套处理并发任务的设计步骤,还提供了一套把实时系统建造成并发任务的标准和定义并发任务间接口的指南。
1.DARTS开发方法的基本概念
任务结构化标准可以为设计人员将实时系统分解为并发任务的时候提供帮助。
信息隐藏作为封装数据存储的标准来使用。信息隐藏模块用于信息数据存储和状态转换表的内容和表示。当有多个任务访问I H M 的时候,访问过程就必须对数据的访问进行同步。
RTSAD 设计方法使用任务架构图来显示系统分解为并发任务的过程,以及采用消息、事件和信息隐藏模块形式的任务间接口。图16-26所示的即为任务架构图所使用的表示法。
2.DARTS 开发过程
DARTS 方法组成(表格版)
| 阶段 | 核心工作 | 主要产出与说明 |
|---|---|---|
| 1) 系统规范开发 | 采用RTSA建立系统模型 | 系统环境图SCD、状态转换图STD、分层DFD/CFD;明确状态与数据/控制转换关系 |
| 2) 划分并发任务 | 按流图叶子节点拆分任务 | 初步任务架构图TAD;I/O转换→异步/周期/I/O任务;内部转换→控制/周期/异步任务 |
| 3) 定义任务间接口 | 明确交互方式与时序约束 | 数据流→消息接口;事件流→信号;数据存储→信息隐藏模块;更新TAD;做时间约束分析与时间预算分配 |
| 4) 设计每个任务 | 任务内部模块化设计 | 用结构化设计拆分模块;定义模块功能与接口;用PDL描述模块内部逻辑 |
| 5) 设计成果 | 输出全套设计文档 | RTSA规范、任务结构规范、任务分解(模块+接口+PDL详细设计) |
3.DARTS 开发方法的评价
DARTS开发方法优缺点对比表
| 对比项 | 具体内容 |
|---|---|
| 主要优势 | 1. 强调系统分解为并发任务 ,并提供任务划分标准 2. 提供任务间接口定义 的详细指南 3. 重视任务架构图(TAD) ,适配实时系统设计 4. 支持从 RTSA 规范到实时系统设计的完整转换,有明确分解规则与设计步骤 |
| 不足之处 | 1. 数据封装不如 NRL、OOD 完善,仅用 IHM 封装数据存储,仍采用结构化设计实现任务模块 2. 高度依赖 RTSA 阶段成果,若前期规范不完整,后续任务划分会非常困难 |
16.4嵌入式系统软件架构案例分析
16.4.1鸿蒙操作系统架构案例分析
鸿蒙 (HarmonyOS) 整体采用分层的层次化设计,从下向上依次为:内核层、系统服务层、框架层和应用层。系统功能按照"系统"→"子系统"→"功能/模块"逐级展开,在多设备部署场景下,支持根据实际需求裁剪某些非必要的子系统或功能/模块

1.鸿蒙的层次化分析
HarmonyOS 四层架构
| 层次 | 核心组成 | 主要功能 |
|---|---|---|
| 内核层 | 内核子系统 + 驱动子系统 | 多内核设计,通过 KAL 屏蔽内核差异,提供进程/线程、内存、网络等管理;HDF 提供统一驱动框架 |
| 系统服务层 | 系统基本能力、基础软件服务、增强软件服务、硬件服务四大子系统集 | 提供分布式软总线、数据管理、任务调度、运行时、多媒体、AI、设备专属业务及硬件服务,支持灵活裁剪 |
| 框架层 | 多语言程序框架、Ability 框架、API 接口 | 提供 Java/C/C++/JS 开发框架与开放 API,支持组件化裁剪,适配不同设备 |
| 应用层 | 系统应用 + 第三方应用 | 基于 FA(有界面交互)、PA(无界面后台服务)开发,支持跨设备调度,实现统一体验 |
2.鸿蒙操作系统的架构分析
四大技术特性
| 特性 | 核心内容 |
|---|---|
| 分布式架构跨终端协同 | 基于分布式软总线、数据管理、任务调度、虚拟外设,屏蔽底层复杂度,实现多设备无缝协同 |
| 确定时延引擎+高性能IPC | 按优先级与时限调度,响应时延降低25.7%;微内核使IPC效率提升5倍,系统更流畅 |
| 微内核+形式化方法可信安全 | 微内核精简、服务用户态实现;首次在终端TEE用形式化验证全路径,代码量仅Linux千分之一,攻击面大幅降低 |
| 一次开发多端部署 | 统一IDE、方舟编译器、多语言统一编译、界面自动适配,实现跨设备生态共享 |
分布式四大核心能力
| 分布式能力 | 作用 |
|---|---|
| 分布式软总线 | 统一通信基座,设备快速发现、连接、数据传输 |
| 分布式设备虚拟化 | 多设备融合为超级虚拟终端,业务跨设备连续流转 |
| 分布式数据管理 | 数据不与设备绑定,跨设备数据无缝衔接 |
| 分布式任务调度 | 跨设备远程启动/调用/迁移,智能选择最优设备执行任务 |

16.4.2面向安全攸关系统的跨领域GENESYS系统架构案例分析
GENESYS(GENeric Embedded SYStem) 是一种跨领域的通用嵌入式架构平台
GENESYS 架构核心解决思路
| 面临挑战 | 核心解决思路 | 关键技术手段 |
|---|---|---|
| 复杂性管理 | 提升设计抽象级别,管理日益复杂的应用与处理能力 | 基于接口的软硬件构件化、消息交换、抽象/分区/分段简化设计 |
| 系统健壮性 | 在故障与误操作下仍能正常提供服务 | 故障隔离框架、构件可选择性重启、复制容错、全层次信息安全 |
| 能量有效使用 | 满足移动设备低功耗需求,提升能效 | 综合资源管理、构件迁移到 ASIC、功率门控、时间触发的绿色通信机制 |

GENESYS 架构服务分类
| 服务类别 | 子类别 | 特点与说明 | 典型示例 |
|---|---|---|---|
| 领域无关服务 | 核心服务 | 强制性、最小服务集;用于构建高层服务、保障架构基本性质;需认证,要求确定性、简单性 | 全局时间、消息传输 |
| 选择服务 | 基于核心服务扩展,按需选用;可与通用中间件(GEM)配合,消息通信;成熟后可硬件化以提升能效 | 信息安全服务、外部存储管理、Internet网关 | |
| 领域专用服务 | 领域专用中心服务(DSC) 领域专用选择服务(DSO) | 面向特定行业领域,由通用选择服务子集+领域特有服务组成 | 汽车领域:CAN总线网络服务 |
| 应用专用服务 | --- | 面向具体应用,包含中间件 | 业务专属应用服务 |
16.4.3物联网操作系统软件架构案例分析
物联网 (Internet of Things,IoT) 是指通过信息传感设备,按约定的协议,将任何物体与网络相连接,物体通过信息传播媒介进行信息交换和通信,以实现智能化识别、定位、跟踪、监管等功能。
在物联网应用中有三项关键,分别是感知层、网络传输层和应用层。
物联网操作系统通常包括了芯片层、终端层、边缘层、云端层等多个层面内容。
物联网操作系统主要特征
| 特征 | 说明 |
|---|---|
| 内核尺寸伸缩性 & 架构可扩展性 | 适配不同物联网场景,架构灵活可扩展,支持内核大小裁剪 |
| 内核实时性 | 属于强实时系统,对中断响应、多任务调度有高实时性要求 |
| 高可靠性 | 海量节点难以现场维护,要求平均无故障时间长、可在严苛环境稳定运行 |
| 低功耗 | 节点数量多、续航要求高,采用休眠、节能、降频等技术延长工作时间 |
