Page 278 - 《软件学报》2026年第3期

徐雄 等: 嵌入式软件 IP 通用模型 1241

made by the system about the environment and platform, representation and utilization of the immediate knowledge of software,
correctness of model assembly, and relations between model and implementation. Therefore, this method has remarkable advantages. The
proposed general model reveals the essential nature of software construction to some extent. Software is not merely a set of codes, but
should be a combination of knowledge, specification, and codes. Additionally, for simplifying the utilization, this study shows software IP
in different views according to the utilization purposes (focuses). Finally, this study puts forward an approach of extracting software IP
from existing embedded software assets and validates the effectiveness of this extraction method through practical cases.
Key words: embedded system; software IP; intelligent synthesis; knowledge; formal model

复杂嵌入式系统广泛应用于国民经济、国防等关键领域, 例如航空航天、轨道交通、核电等. 在这些领域, 一
方面嵌入式系统实现功能越来越多, 软件规模变得越来越庞大和复杂; 另一方面, 系统安全至关重要, 如果发生错
误将会给生命和经济等带来重大灾难性后果. 因此, 如何高效开发可靠的复杂嵌入式软件是一个重大挑战. 嵌入式
系统通常具有如下几个关键特性.
(1) 硬件依赖: 嵌入式系统包括硬件和软件的组合, 软件需要通过硬件才能与物理环境进行交互, 并且软件的
性能依赖于硬件平台的配置.
(2) 领域相关: 嵌入式系统的设计通常是面向领域的, 不同的领域对系统的关注点也不同.
(3) 资源限制: 嵌入式系统都是以尽可能少的资源运行所需的计算.
(4) 实时性: 嵌入式系统必须对环境的实时变化做出相应的反馈.
(5) 安全性: 嵌入式系统的运行错误可能导致灾难性后果.
基于嵌入式系统的这些特性, 人们提出了各种提高嵌入式软件开发效率和质量保障的方法. 这些方法的基本
思路是通过抽象/精化、组合/分解、软件复用等技术, 对软件进行建模和封装, 构造能够复用的软件功能单元, 最
后将不同的软件单元进行组合形成满足需求的嵌入式软件系统.
目前主流的方法包括模型驱动设计 (model-driven design, MDD) [1−5] 、基于构件的设计 (component-based
design, CBD) [6−9] 和基于契约的设计 (design by contract, DbC) [10] 等. MDD 从嵌入式系统的需求出发, 首先构造满足
需求的抽象模型, 进而对模型进行仿真、测试和验证, 最后生成模型的代码. MDD 的模型模块的功能是独立的、
完整的, 但是, ① MDD 主要通过仿真发现设计中的错误, 而仿真无法覆盖系统的所有运行场景, 因此会有设计缺
陷在系统实现时甚至部署后才被发现; ② 并不是所有代码都可以基于模型自动生成, 并且模型和实现之间的一致
性难以保证; ③ MDD 难以描述模型功能及对其他模块和执行平台的假设和约束. CBD 将软件封装成可复用的构
件, 通过对可复用的构件进行组装来进行软件资产的重复利用. CBD 中具有详细的功能描述和接口协议, 但是,
① 构件对嵌入式环境的假设以及对环境保证的行为的规约描述尚显不足; ② 由于构件缺乏明确的统一标准并且
构件通常由不同人员开发, 导致文档不全, 质量得不到保证, 由构件组装成的嵌入式系统的正确性很难直接由构件
的正确性保证, 存在构件的错误使用和配置的风险; ③ 构件只是功能的部分实现, 需要通过请求接口请求外部的
服务才能完全实现构件的功能, 因此构件不是功能独立的; 此外, ④ 构件采用的请求/提供服务模式更适用于分布
式系统, 而不是专门针对嵌入式系统. DbC 使用严谨的数学语言对构件的行为、构件之间的交互以及关于环境的
假设建立形式化规约, 部分解决了构件可理解性和正确组合的问题. 然而, ① DbC 中的构件不是功能完整的, 它缺
少对实现和功能的具体描述, 对契约的描述和证明通常需要人工参与, 很多研究尚停留在理论阶段; ② 忽略了契
约与实现间的关系, 很难灵活实现已有软件资产的复用. 总而言之, 现有这些主流方法的缺陷主要体现在以下几点.
(1) 未能充分考虑嵌入式系统的资源受限和实时性等关键特征.
(2) 在嵌入式环境及平台的要求和假设方面存在表述不清晰的问题.
(3) 未能充分重视对中间知识的表示和使用.
(4) 系统的正确性难以由组成它的模块的正确性保证.
(5) 忽略了模型与实现之间的关系.
此外, 嵌入式系统的实时和资源需求、与物理环境的深度融合也对以上这些方法构成挑战.
相对于软件领域的系统开发, 硬件领域提出硬件 IP (intellectual property) 的概念 [11−13] , 对芯片中常用的功能模