4. BSP需求分析与交付规格书编写

BSP（Board Support Package）需求分析的本质，是把航电计算平台顶层的系统需求，逐层分解为可被BSP实现、可被测试验证、可被交付验收的工程条目。系统需求通常描述“平台应支持什么能力”，例如“支持ARINC 653分区调度”“支持机载以太网通信”“支持BIT上电自检”；而BSP需求必须回答“在什么硬件上、通过什么接口、达到什么指标、以什么证据证明”。这一转换过程如果只做文字转抄，交付阶段必然出现“系统说支持、BSP说没实现、测试说无法验证”的三方扯皮。

一、从系统需求到BSP需求的分解方法

推荐采用“功能—接口—性能—约束”四维分解法。以“支持ARINC 653分区调度”为例：功能维度分解为分区创建、分区切换、分区时间窗配置、分区健康监控；接口维度分解为分区配置表接口、分区服务调用接口（如GET_PARTITION_STATUS）、错误处理接口；性能维度分解为分区切换时间、时间窗抖动、最大分区数；约束维度分解为DO-178C DAL等级、目标处理器架构、编译器版本。分解后的每一条BSP需求都应具备唯一编号、来源追溯、验证方法和验收准则。

分解过程中要特别警惕“隐含需求”。例如系统需求写“支持多核处理器”，BSP层面必须追问：核间通信机制是什么？共享内存如何保护？中断如何路由？缓存一致性由硬件保证还是软件维护？这些隐含需求若不显式写入规格书，后期集成时往往成为进度杀手。建议在分解时同步建立“需求—硬件—软件—测试”四向追溯矩阵，确保每条BSP需求都能找到对应的硬件资源、软件模块和测试用例。

二、接口需求与性能需求的编写要点

接口需求是BSP规格书中最容易产生歧义的部分。以机载以太网通信为例，不能只写“支持AFDX通信”，而应明确：端口号、虚拟链路标识、带宽分配间隔（BAG）、最大帧长、冗余管理策略、完整性检查与冗余检查的启用条件。对于ARINC 653分区服务接口，应逐条列出服务名、参数类型、返回值范围、调用上下文（分区内/内核态）、错误码定义。接口需求建议采用表格形式，字段包括接口编号、接口名称、方向（输入/输出/双向）、数据类型、取值范围、默认值、异常处理。

性能需求必须可量化、可测量。例如“分区切换时间≤50μs”应补充测量条件：在目标处理器主频XXX MHz、L1缓存命中率≥90%、无DMA竞争的条件下，从调用切换服务到目标分区第一条指令执行的时间。时间窗抖动应明确为“相对于配置时间窗的偏差绝对值≤5μs”。对于BIT自检，应区分上电自检（PBIT）、周期自检（CBIT）和维护自检（MBIT），分别规定检测覆盖率、检测时间、故障隔离粒度。性能需求若缺少测量条件，测试阶段就无法判定合格与否。

三、交付规格书模板与评审要点

一份可执行的BSP交付规格书建议包含以下章节：1）范围与引用文件；2）硬件平台描述（处理器、内存、外设、中断控制器、时钟树）；3）BSP功能需求（按模块分组，每条含编号、描述、来源、优先级、验证方法）；4）接口需求（API列表、数据结构、错误码）；5）性能需求（指标、测量条件、验收准则）；6）约束与假设（DAL等级、编码标准、工具链版本）；7）交付物清单（源码、二进制、配置表、文档、测试报告）；8）验收准则与评审检查单。模板不是越厚越好，关键是每条需求都能被追溯和验证。

评审要点应聚焦五个方面：完整性——系统需求是否全部覆盖，隐含需求是否显式化；一致性——接口定义与硬件手册、操作系统手册是否一致；可验证性——每条需求是否有明确的验证方法和验收准则；可追溯性——需求编号是否与系统需求、测试用例双向关联；可行性——性能指标在目标硬件和工具链下是否可达。评审时应邀请系统、硬件、软件、测试四方参与，重点检查跨边界接口和性能指标，避免“各自都懂、合起来不通”。

最后需要强调：BSP需求分析与规格书编写不是一次性文档工作，而是贯穿交付与维护的基线。当硬件版本升级、OS补丁更新或适航审定提出新要求时，规格书应同步修订并重新评审。维护阶段的问题定位、回归测试范围确定、版本变更影响分析，都依赖这份规格书的质量。把需求写清楚，后续的交付、测试和维护才有稳固的起点。