软件版本

软件版本（精选5篇）

软件版本 篇1

医疗器械软件包括本身预期作为医疗器械的软件(独立软件)和作为医疗器械内部组成部分的软件(软件组件)[1]。美国FDA召回数据表明含有软件的医疗器械的召回原因有33.7%与软件有关[2],而医疗器械软件的召回原因有79.3%由软件变更导致[3]。因此,必须加强医疗器械软件的监管工作,特别是对医疗器械软件变更的监管。

在软件工程中,软件版本用于标识软件状态,控制软件变更,在保证软件质量方面发挥着不可替代的重要作用。不过,当前业内对于软件版本在医疗器械软件监管中的作用认识不足,甚至还存在着误区,这将不利于我国医疗器械软件监管工作的开展。

1 软件版本在软件监管中的作用

软件是无形的,没有物理实体,无法直接进行质量控制,只能通过状态管理来保证软件质量。而软件版本是软件状态管理的工具,软件版本与软件是表里的关系,也是相互对应的关系,即软件发生变更软件版本也随之变化,而且软件发生不同类型和程度的变更,软件版本的不同字段也随之变化,反之亦然。这样通过软件版本就可以识别软件状态,从而在软件整个生存周期过程中进行质量控制以保证软件质量。

国际医疗器械监管者论坛(IMDRF)近期发布的有关文件明确医疗器械唯一标识(UDI)由器械标识(DI)和生产标识(PI)组成,DI的改变需要提交新的上市申请。对于普通医疗器械,产品标签采用DI即可,无需体现PI。而对于独立软件,产品标签需要同时采用DI和PI,软件版本即为PI或PI的组成部分[4],这表明软件版本是独立软件产品标签不可或缺的组成部分。而软件组件不能单独上市,需要随医疗器械产品共同上市,虽然不涉及产品标签的问题,但同样需要软件版本进行质量控制,故此时软件版本是制造商的内部标识。

由此可知,软件版本不仅是医疗器械软件质量控制的工具,是制造商质量管理体系的组成部分,而且是医疗器械软件的产品标识或内部标识,是实现医疗器械软件可追溯性的重要工具。因此,软件版本在医疗器械软件的监管中发挥着重要的作用。

2 软件版本认识误区及监管必要性

2.1 认识误区解析

欧美医疗器械软件上市批书并未强制要求体现软件版本,即便是独立软件也是如此,业内对此现象的常见解释是:一方面软件变更频繁且迅速,上市批书如体现软件版本就会导致软件需要不断进行上市申报,另一方面软件版本已在制造商质量管理体系中进行要求,上市前审批无需重复要求,故欧美医疗器械软件上市批书无需体现软件版本,进而认为中国也应如此。下面简单分析一下欧美对于医疗器械软件的监管要求,探寻上述现象的内在原因。

首先,欧美监管机构规范了软件质量管理体系的考核要求,如欧盟制定了软件生存周期、软件风险管理等标准或技术报告[1,5],美国FDA制定了软件确认、设计控制等指南[3,6]。其次,欧美监管机构建立了软件变更(即版本变更)的监管机制,如欧盟要求制造商每年向认证机构提交软件变更的情况说明,由认证机构来判定是否需要提交新的上市申请;而美国FDA的PMA方式与欧盟要求相同,510k方式有变更申报指南[7],制造商据此可判断软件变更是否需要提交新的上市申请,如无法判断可直接提交上市申请由美国FDA判定,而美国FDA会在后续质量管理体系考核予以确认。最后,欧美监管机构要求在上市申报资料(如说明书)中体现软件版本,如美国FDA软件申报指南明确要求制造商在修订历史中描述软件发布版本[8]。

因此,欧美监管机构从多个角度建立了软件版本确认的相关机制,故无需在上市批书中体现软件版本。同时,欧美监管机构也可在上市批书等官方证明材料中明确软件版本,这也佐证了欧美监管机构已在前期软件监管工作中对软件版本进行了确认。

2.2 监管必要性

我国目前由于监管资源和监管条件的限制,尚未建立起与欧美类似的医疗器械软件监管机制,同时我国的国情和监管体制也与欧美不同,所以不能简单盲目照搬照抄欧美软件版本的监管方法,否则可能会出现医疗器械软件在中国违法上市的情况,特别是境外的医疗器械软件。

我国监管法规明确要求境外医疗器械只有在原产国获准上市后方能在中国进行上市申报,但我国对境外医疗器械制造商未开展质量管理体系考核工作,故未对软件版本进行确认,上市前审批如对软件版本不做要求就存在着监管漏洞。举例而言,某境外独立软件1.0版已在原产国获批上市,经过重大变更后升级至2.0版,但产品名称保持不变,因不在原产国销售故未进行上市申报,即该软件2.0版在原产国未获准上市,如果原产国上市批书等官方证明材料未体现软件版本,那么该软件2.0版就可以在中国进行上市申报并获准上市,这就违反了我国监管法规的要求。

同理,境内医疗器械软件也会出现类似情况,例如,软件发生影响到安全性和有效性的重大变更,本应提交新的上市申请获批后才能上市销售,但如果质量管理体系考核、上市前审批和上市后市场监督不能有效配合,就会出现该软件未获批就上市销售的情况。

因此,当前我国医疗器械软件的监管工作必须要结合软件版本,而且需要从质量管理体系考核、上市前审批和上市后市场监督各个环节对软件版本进行监管,方能实现医疗器械软件的有效监管。

3 思考与建议

软件具有特殊性,变更频繁且迅速,轻微变更也可能导致严重后果。从监管的角度出发,不仅要考虑软件自身特点以及软件变更对医疗器械安全性与有效性的影响,而且要考虑监管资源的有限性以及软件频繁变更导致的注册申报负担。在保证软件版本真实准确反映软件状态的前提下,可以基于软件版本来实现医疗器械软件的有效监管。

3.1 软件版本命名规则设定

医疗器械软件虽然是软件工程在医疗器械行业的延伸,但软件工程所用的版本命名规则不一定符合医疗器械的监管要求,如采用软件发布日期和软件发布顺序编号作为软件版本的情况,所以医疗器械软件的版本命名规则需要考虑监管要求,特别是对软件变更的监管要求。

例如,如果监管要求明确医疗器械软件发生增强类变更需要提交新的上市申请,而发生纠正类变更和内部构建通过质量管理体系进行控制,无需提交新的上市申请[9],那么软件版本命名规则就需要区分软件变更类型。此时,软件完整版本用于描述软件所有类型的变更,而软件标识所用版本仅体现增强类变更即可,当软件标识所用版本发生改变则需要提交新的上市申请。例如,软件版本命名规则为X.Y.Z.B,其中X表示重大的增强类变更,Y表示轻微的增强类变更,Z表示纠正类变更,B表示内部构建,则软件标识所用版本可省略为X.Y,此时如X和Y发生变化则需提交新的上市申请,而Z和B如发生变化则无需提交新的上市申请。

同时,对于独立软件而言,软件标识所用版本可作为DI或DI的组成部分,软件完整版本则作为PI或PI的组成部分,这样也符合IMDRF关于独立软件UDI的要求,即独立软件发生重大变更时DI和PI均会随之改变,而发生轻微变更时DI保持不变而PI会随之改变。另外,如果软件版本不能区分软件变更类型,那么从风险角度考虑只能按照增强类变更的要求进行监管。

3.2 软件组件版本监管

软件组件和独立软件从设计和生产角度而言差异较大,但从监管角度而言差异并不明显,如欧盟软件生存周期标准、软件风险管理技术报告均适用于全部医疗器械软件,并不限于独立软件[1,5],而美国FDA软件确认指南、设计控制指南、软件申报指南和产品变更申报指南也不区分独立软件和软件组件,同样适用于全部医疗器械软件[3,6,7,8]。

尽管软件组件无需外部标识,其版本仅用于内部标识,但独立软件的版本监管原则同样适用于软件组件,原因在于软件版本是软件质量控制和实现可追溯性的工具,无论独立软件还是软件组件均适用。同时,软件组件如发生重大变更同样需要提交新的上市申请,如不对软件组件的版本进行监管也会出现医疗器械产品违法上市的情况。因此,软件组件和独立软件关于版本的监管要求是相同的,差别仅在于软件组件无需外部产品标签,但仍需在上市申报材料、产品说明书和产品注册证中体现版本。

3.3 软件版本监管方案建议

结合我国医疗器械软件的监管现状,可以基于软件版本建立一个医疗器械软件的监管方案,其前提是软件变更监管的法规要求,其核心是软件版本命名规则,其关键是软件版本命名规则真实性核查。

首先,衡量监管风险明确软件变更监管的法规要求。这是医疗器械软件监管的前提和基础,不必追求一步到位与国际全面接轨,可以结合我国监管体制和监管资源分阶段开展相应工作,积累监管经验逐步完善监管要求。软件变更类型及其监管要求可以参考3.1节举例所述内容,以后待时机成熟时可将轻微的增强类软件变更豁免上市申报。另外,与召回有关的软件变更需要依据相应的法规进行处理。

其次,制造商需结合软件特点和监管要求来规范软件版本命名规则,明确软件版本的全部字段和字段含义,并确定软件标识所用版本。制造商需要在产品说明书体现软件标识所用版本,同时还需在开机或登录界面显示软件标识所用版本,而在“帮助”或“关于”界面显示软件的完整版本,无论独立软件还是软件组件均适用。

最后,质量管理体系考核、上市前审批和上市后市场监督均需对软件版本命名规则进行真实性核查。境内质量管理体系考核可通过软件配置管理文件或项目开发文件来确认软件是否依据版本命名规则进行设计、开发和维护。制造商在上市申报材料中需出具软件版本命名规则真实性声明,明确版本命名规则和标识所用版本,承诺承担相应的法律责任;同时境外医疗器械软件的上市批书等官方证明材料需明确软件标识所用版本。软件检测报告提供软件开机或登录界面以及“帮助”或“关于”界面的照片。技术审评基于检测报告照片、制造商真实性声明和软件申报技术资料来确认软件的完整版本和标识所用版本。产品注册证体现软件标识所用版本和软件版本命名规则等信息。上市后市场监督依据产品注册证关于软件版本的相应信息进行上市后监管。

这样一方面基于软件变更监管的法规要求,可以减轻制造商的注册负担,节省监管资源,另一方面通过各个监管环节的多管齐下,可以增加制造商的违法成本,强化监管效果,在促进医疗器械行业技术进步与创新的同时有利于实现医疗器械软件的有效监管。

总之,医疗器械软件及软件变更的监管是当前业内所关注的热点之一,也是当前医疗器械监管的重要课题之一[10,11,12]。我国医疗器械软件的监管工作可以借鉴国外经验但不能简单盲目照搬照抄,而且需要综合考虑我国的国情、监管体制、监管资源和监管条件,可以将软件版本作为切入点来探寻医疗器械软件的监管方案。

软件版本 篇2

第一章 目的

本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。

1.第二章 适用范围

所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。

2.第三章 职责

配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。

此岗位可由开发或测试人员兼任。

3.第四章 内容

4.1.版本管理对象

包括但不限于：

 项目总体计划

 可行性研究报告

 开发计划

 需求说明书  需求设计原型

 设计说明书

 系统开发变更申请单

 系统管理手册

 用户操作手册

 培训计划

 培训记录

 源程序

 支持系统运行的配置文件

 存储过程脚本

 测试计划

 测试用例

 测试脚本

 测试报告

 上线计划

 上线申请

 版本维护日志

4.2.配置库的目录结构

每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。配置库目录结构规划：

┠tags(发布)

┃ ├v1.0.0_T1_2016909 ┃ ├v1.0.0.33899_T1_20161009 ┃ ├v1.0.0_R1_20161109 ┃ ├v1.1.0_T1_20170109 ┃ └v1.1.0_R1_20170209 ┠trunk(主版本)┃ └projectA ┃ ├src ┃ ├MY_MOOC ┃ ├doc ┃ ├tool ┃ ├。。

┖branches(分支)├SY_ABC ├TJ_ABC ├WH_MOOC

其中，项目内部的目录结构：

|–projectA |–src（保存该项目的源程序）

|–doc（保存项目相关文档）

|–000.项目管理（保存项目过程管理相关文档）

|–010.项目计划（保存项目计划相关文档）

|–020.项目需求（保存项目需求相关文档）

|–030.系统设计（保存项目设计相关文档）

|–030.系统测试（保存项目代码测试相关文档）

|–040.系统实施（保存项目部署实施相关文档）

|–050.系统运维（保存项目运维文档，包括培训、用户手册等）

|–060.技术资料（保存项目技术文档，包括第三方技术资料等）

|–。。（保存项目过程管理相关文档）

|–tool（包括该项目特定的开发、编译、测试等工具）

4.3.分支(branch)

建议使用分支来协同不同职能小组对同一个配置库的使用，可按照以下方式进行分支的管理。

解决方案建立三个分支，包括主版本开发(trunk)、分支版本开发(branches)和发布(tags)。

 主版本开发

是所有分支版本的基准版本，主版本的开发分支。开发部门开发使用。

 分版本开发 主版本的分支版本，供开发部门开发使用。开发工程师如果以主版本为基准，进行软件项目开发，要先将trunk目录下的代码分支到branches目录的一个子目录，在那里对代码进行开发。多个主版本的分版本可通过在branches顶级目录创建多个分支目录来区分。

 发布

测试和发布专用分支，该分支代码不允许任何形式的修改。每个经过测试后的不同版本的代码做快照放到此分支文件夹下。

4.4.权限管理

应对配置库的访问权限进行管理，确保软件系统的完整性和安全性。建议按如下方式进行管理。

4.4.1.开发工程师

仅拥有自己所属项目的add file、delete file、check out、check in权限，无目录创建和删除权限。开发工程师若想创建目录，需向配置库管理员申请。

4.4.2.测试工程师

拥有每个项目的测试分支的add file、delete file、check out、check in权限，无目录创建和删除权限，对于其他分支只有只读权限。

4.4.3.配置库管理员

拥有全部权限，但增删项目和增删目录需要有项目负责人批准。

4.4.4.其他人员

若需要配置库访问权限，需经技术总监或经技术总监授权的项目经理批准，由配置库管理员分配权限。

4.5.版本管理

应对软件系统的版本进行管理，确保版本的准确性和可追溯性。建议按如下方式进行管理。

4.5.1.版本维护

软件工程各阶段产生的各种文档和代码，应及时并统一上载到配置库由配置库管理员统一管理。对于要修改的配置项，应从配置库中检出（check out）后修改，修改完毕后及时检入（check in），并填写修改的原因和内容。配置项的历史版本应保存在配置库中。

4.5.2.分支迁移

从开发分支到测试分支的迁移，由开发工程师操作。迁移的时机有：

1.当开发负责人提交测试申请时；

2.开发过程中进行测试，修改好一个或多个bug，需要测试工程师验证时。

从测试分支到发布分支的迁移，由配置库管理员操作。迁移的时机有：

1.当开发组提交上线申请时。

对于每个项目从测试分支到发布分支的迁移，配置库管理员要建立分支迁移日志，并详细记录。

4.5.3.版本升级

软件系统迁移到发布分支后，生成新的版本。

每个系统新的版本不仅以分支形式存在于配置库中，并且要以独立压缩包形式备份。版本的命名规则为，version N1.N2.N3[.N4][_][T/R5]_YYYYMMDD 1.N1是系统编号。当项目整体重新设计时，N1加1，基数为1 2.N2是模块编号。当模块重新设计时，N2加1，基数为0

3.N3是功能编号。当项目增加某一功能，或某一功能需要修改时，N3加1，基数为0

4.N4是BUG编号。当项目的BUG被修复时，N4加1，基数为0

5.T/R5中的T/R分别对应Test/Release。当项目发布时为R，当项目提交测试时为T，T/R5数值基数为0，以发布/测试提交顺序递增加1。

6.YYYYMMDD代表生成版本的实际年月日，如：20160202 4.5.4.版本基线定义

公司首次采用版本管理规范时，可以采取下列方法定义一个基线版本。

获取各项目最新的源程序、配置文件和文档，形成发布分支、测试分支和开发分支。

对每个项目的提测和发布分支都生成一个版本基线，如：Version1.0.0_R1_20160202。

4.6.第五章 版本提交准则

4.6.1.提交之前先更新

更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。

如果在修改的期间其他同事也更改了同一个文件，那么update更新时会自动进行合并，如果修改的是同一行或者二者修改差异过大，那么合并时会产生冲突。这种情况就需要同之前的开发人员联系，两人一起协商解决合并冲突。解决合并冲突之后，还需要两人一起测试，以保证解决冲突之后，各自的程序不会受到影响。

在更新时注意所更新文件的列表，如果提交过程中产生了更新，则需要重新编译并且再次完成单元测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免合并错误导致代码有错。

4.6.2.保持原子提交

为确保在需要时可以随时回溯代码版本，每次提交的代码只能包含实现一个独立、完整功能所必需的代码，不能夹带提交其他与此功能不相关的代码。为尽早提交，也可以将此独立、完整功能分解为若干小细节功能，分别开发并提交所必需的代码，但必须确保多次提交的功能代码组合在一起，完全实现此独立、完整功能。

仅提交自己修改的部分，最好不要一下子将整个项目提交。

每完成一个独立、完整的功能后，最好尽早提交，以免后续更改时出现bug，无法恢复到正常代码。

每次提交的间歇尽可能地短，以几个小时的开发工作为宜。我们提倡多提交，也就能多为代码添加上保险。为做到尽早提交，在开发功能模块的时候，先将功能分解成一个个独立的、不可再分割的小细节功能，分别完成。每完成一个并通过单元测试，就提交一次。在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。

4.6.3.不要提交本地自动生成的文件

一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交（例如Eclipse中的.classpath文件等，Visual Studio中的.suo文件，Debug,Release,Obj等编译文件夹及其下文件，以及其他的一些自动生成，同编译代码无关的文件）。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件，如果不小心签入了，需要从配置库中删除，以免其他同事在更新后就可能与本地的环境冲突从而影响大家的工作。

4.6.4.不要提交不能通过编译的代码

代码在提交之前，首先要确认自己能够在本地编译通过，并且代码在提交前已经通过自己的单元测试。

如果在代码中使用了第三方类库，要把相应类库文件统一存储在代码相应目录中并提交，以免项目组成员中有些成员可能没有安装相应的第三方类库，从而在更新代码后引起代码运行错误。

4.6.5.不要提交自己不明白的代码

代码在提交之后即被项目成员所分享。如果提交了不明白的代码，自己看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保对这个代码有一个很清晰的了解（必要时应有对应文档说明）。

4.6.6.并行开发（同一模块）前沟通

如果开发小组采用并行开发模式开发同一模块功能，在开发前，需要对协作开发进行合理的工作计划与任务分配，让小组成员相互间了解对方的工作计划与工作内容。这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时也能够在和成员的交流中发现自己之前设计的不足，完善自己的设计。4.6.7.对提交更新的信息采用明晰的标注

如果提交空的标注或者不确切的标注将会让项目组中其他的成员不了解此次签入动作的背景情况（如新增/修改签入的原因是什么？新增/修改什么内容？），项目经理无法通过提交的标注信息，清晰的掌握开发工作进度细节进度。没有清晰标注，甚至会对回溯代码版本造成影响。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。统一的标注格式为：

签入动作+””+”#” +标识ID+”;”+签入内容+[“;”]+[签入原因] 签入动作：

+：表示增加了功能（新增功能）

*：表示对某些功能进行了更改（修改功能）

-：表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽（删除功能）

^：表示修正bug（修复功能缺陷）

！：优化功能代码的执行性能（代码性能优化）

标识ID：

ID值是从项目开发计划中的WBS任务分解表中获取，对应具体功能编号。

签入内容：

对新增/修改/删除 的内容进行简单描述

签入原因： 对修改/删除 的原因进行简单描述

示例：

+ #62235；新增房源审核功能

* #62236；将房源审核的二级审核修改为一级审核；为缩短业务流程长度，提高业务响应速度

-#62237；删除多余功能；房源审核由二级审核改为一级审核后删除无用功能

软件版本 篇3

我们是从http://www.skystar-2.com/download/AltDVB2.2.exe网址下载的Alt-DVB v2.2 B3912 Full全能程序包，它包含了DirectShow SDK Filter Graph Editor图像解码包、双汉卡、DVBWorld 等多种卫星多媒体接收卡驱动程序，Cyberlink、Dscaler、Intervideo、Nvidia等多种DVB音视频解码插件，解密插件EmuNation、vplug 和 146°E的自动升级程序，文件大小为3.41MB。也就是说电脑只要安装该包就可以播放卫视信号，而不必像之前的版本还要安装诸如SDK的底层程序和其它驱动插件。

AltDVB软件设置

下载完成后，点击AltDVB2.2.exe程序进行安装，默认安装路径为C:Program FilesAltDVB，安装完成后，点击AltDVB启动软件，弹出选择驱动界面（图2），选择第一项“Dev_Twinhan”，并点击“Set default”按钮，将它设置为默认，以便每次启动软件时，能够自动加载该驱动程序。

1、添加卫星设置

启动AltDVB软件，首先进行卫星添加设置，选择左上角的【Scan】项目，在弹出的界面上右键选择“Add satellite”添加卫星（图3）。

弹出卫星选择列表，我们的卫星接收采用如图4所示的一机六星接收设置方案。

以选择76.5°E的亚太2R卫星，将光标移动到该卫星名称上，双击它，如图5所示。

如果你需要添加的卫星在该列表中没有，如70.5°E的EUTELSAT W5（欧星W5），可以通过C:Program FilesAltDvbSatFiles，打开AllSats文本文档，进行添加编辑（图6）。实际上还可以将一些无用的卫星名称删除，一些陈旧的卫星名修改为现行使用的新卫星名。

在弹出的添加卫星的高频头、切换开关设置界面中（图7），【satellite】区域无需设置；【LOF Settings/LNB Type】区域为高频头本振设置，我们采用是9750/10600MHz的双本振Ku头，点击“Select”按钮，选择“KU-Linear”即可，其中11700为高低本振的转折频率；在【DiSEqC Switch 1】区域为DiSEqC切换开关设置，我们采用的是四切一，因此在【Type】项目内选择“Committed”，接收76.5°E卫星的高频头接在四切一的1端口，因此选择“LNB1”。

设置完成后，点击“Save”保存并退出，再用上述同样的方法添加105.5°E亚洲3S和138°E亚太5号卫星，不过我们接收105.5°E和138°E卫星的高频头是通过0/22k开关接在四切一的2端口。由于AltDVB软件没有0/22k开关的组合设置选项，并且对1020卡采用C波段高频头的本振频率无法准确探测，致使很多烧友认为该软件不支持C波段高频头设置，其实这是设置方法错误和AltDVB软件在应用到1020卡上的一个Bug共同所致。

虽然在AltDVB软件设置菜单上，没有直接对0/22k开关的控制选项，不过该软件切换方式有一个特点：22kHz脉冲信号会根据设定输入的卫星下行频率自行选择是否输出，即当设定LNB为通用型双本振时，设定输入的卫星下行频率低于11.5GHz，无22kHz脉冲信号输出；设定输入的卫星下行频率高于11.7GHz，有22kHz脉冲信号输出；也就是说：低本振对应22k关，高本振对应22k开。

依据这个特点，我们采取了如下的设置方案：

（1）将0/22k开关下所有的LNB本振频率设置为双本振，并且设置高本振为“11300”，对应0/22k开关的22k端口，低本振为“9750”，对应0/22k开关的0端口。

（2）针对软件对双汉卡采用C波段高频头的5150本振频率无法探测的Bug，在直接连接到四切一端口时，将它强行设置为“9750”。

根据上述方案，正确地设置方法是：在这两颗卫星的高频头本振设置项目框（图8）内均填写9750000、11300000数值（注意要多加“000”）。其中“9750000”对应105.5°E卫星，“11300000”对应138°E卫星。实际上两颗卫星可以使用一个设置界面，不过扫描信号后会出现在一颗卫星的频道列表里，不便区分，因此分为两个项目设置。

对于上面的一机六星接收方案，其高频头、切换开关具体设置如表1所示。

2、添加节目参数设置

在所选卫星的界面上右键选择“Scan”项目，出现搜索界面，对于76.5°E 、138°E卫星来讲，可直接使用界面右边提供的信号参数，进行搜索。搜索时，叉选要搜索的转发器，再点击左边的“Scan”按钮即可进行搜索。对于右边列表中未能提供的信号参数，可在其空白区域内右键选择“Add”项目，弹出添加转发器参数界面（图9），按照要求填写下行频率、符码率和极化参数，按Ok后保存后，再进行搜索。

对于上面的100.5°E、105.5°E、166°E卫星来讲，由于所设置的本振频率不在是原来高频头的本振频率，搜索时必须要将下行频率转换一下。可参考表2的换算公式，换算成新的虚拟下行频率，再输入到添加转发器参数设置中。这样软件才会根据虚拟频率的大小，控制接收卡调谐器中的QPSK解调芯片打开或关闭22kHz脉冲信号，以接入我们想要的高频头上，进行信号的搜索或接收。

例如，我们上述接收105.5°E凤凰卫视一组信号（4000 H 26850）时，要输入的新下行频率为14900－4000＝10900，即能够收到信号。如果上面设置方案中四切一的2端口0/22k开关下的138°E 卫星接收的不是Ku波段信号，而是C波段信号，则符合上表中的“C＋C” 方案，如接收3599 V 30000一组转发器，则要输入的新下行频率为16450－3599＝12851。

实际上这种设置方法和4×0系列接收机的多星设置如出一辙，只是AltDVB软件对双汉卡采用C波段高频头的Bug，使得烧友们在设置时大费周折。

3、设置解码插件

当我们搜索好信号后，点击频道列表里的信号，发现并不能播放，出现红色警告界面（图10），这是没有设置好解码插件所致。

在播放图像黑屏的位置，点击鼠标右键，选择“DS Config”项目，在【Automatic】区域内（图11，通过下拉键选择相应的视频/音频插件，设置好后按Save&Restart确认保存，这样，屏幕会出现“waitting……”，不一会儿图像和声音就会出来了。

如果只有图像而没有声音或声音异常，应该重新设置【Graph file】区域内（图12）所选的插件，设置好后按Save&Restart确认保存，即可解决。

双画面播放

AltDVB软件的一个特点是,具有双画面同时实时播放功能，只要点击主界面左边的【PIP】项目键，就会弹出一个副播放画面，如果不能显示画面，采用和上述相同的方法设置好解码插件。对于副画面的选台，可以通过右击画面，在弹出的下拉菜单中选中“Channels List”项目，出现副频道菜单（图13），从中选择所需要播放的频道即可。

不过这个副频道菜单只是你主画面频道所属转发器下的频道菜单，因为在1020卫星多媒体接收卡的硬件上，只有一个调谐器，软件只能解析一个转发器下的TS流，其它转发器下的频道被舍弃。

按动【PIP】下拉菜单中的“Swap PIP”选项，可以互换主副画面信号。在AltDVB2.2版本中，取消了对副画面大小的限制，可以和主画面一样地缩放自如（图14）。

不过当主画面选择其它转发器信号时，副画面会自动关闭。

收看加密频道

由于我们下载的这个全能程序包是推出时间较新，里面携有EmuNation、vplug解密插件和最新的146°E卫星的Nagra系统自动升级程序，直至我们发稿时，仍然可以收看Dream TV加密直播信号，在播放时，选择【Pluglugins】项目，在弹出的解密插件界面里（图15），可以看到解密信息，其中界面的右下【Commands】指令区域显示ECM中的奇偶控制字。

Dream TV直播频道都携有电子频道指南（EPG）信息，只要点击左边的【EPG】项目键，就会弹出该频道播放信号的预告和一些简要注释（图16）。

接收图文信息

图文电视是简单易用的信息服务广播，是一种利用现有的电视频道进行图形、文字信息传输的多工广播。我们知道，电视图像是按照每秒50场（PAL）的速率一场一场的传递，两场之间留有一段不传送图像信息的空隙，称为VBI（Vertical Blanking Interval：场消隐期）。图文信息系统利用时分复用原理将图形、文字信息转换成数字信号叠加在电视信号场消隐期的若干行上，与正常的广播电视信号同时传送，在不影响正常信号广播的同时，传送诸如新闻、天气预报、股票行情等各类社会信息。

在接收图文信息时，一般需要专用的接收机，才能解开相应的图文信息，而1020卡配合AltDVB软件就能够接收到免费的图文信息。对于携有图文信息的信号，软件左边的【Teletext】项目键会自动从灰化中恢复，变为可操作。

如接收100.5°E亚洲2号卫星4000 H 28125这组转发器中的葡萄牙的RTPi频道的图文信息时，只要点击该项目键，就会弹出图文接收界面，刚开始接收时，图文信息在下载中，大约二十几秒钟后下载完成，会显示首页目录（图17），从100开始分页，其内容主要是以资讯为主，如新闻、股市、天气预报、频道预告等。

我们每次重新接收图文信息发现都需要进行页面下载，占用一些时间，其实只要通过进入主菜单，通过【Setings】→【Telext/Subtitles】， 进入图文信息设置界面（图18），勾选第一项“Background TTX parser”转入后台自动处理即可。

该转发器上的另外一个西班牙的TVE频道也有图文信息发送（图19），点击图文界面右下角的下拉按钮，可对图文信息内容进行多种语言选择。

此外，105.5°E亚洲3S卫星上的德国DW-TV频道（3760 H 26000）也有图文信息发送。在国内的卫视频道中115.5°E中星6Ｂ卫星上的河北、湖南、江西、四川等省台也传送图文信息，内容大多数是传送股票实时行情信息。不过由于是加密发送，AltDVB软件不能正常显示，需要专门解码的图文软件才能接收。

信号录制和播放

AltDVB软件具有多种信号的录制功能，不但可以录制普通卫视信号，也可以录制高清信号；不但可以录制多层伴音信号，还可以录制一个转发器下的所有信号。

1、普通信号的录制和播放

在播放状态下，只要点击左边的【Record】项目键，就会弹出一个录制选择界面（图20），点击“Record”按钮即可录制正在播放的信号，录制的信号保存在C:Program FilesAltDvb Records下，录制文件名称由“年月日时分＋频道名称”组成，如果要停止录制，只要再点击左边的【Record】项目键即可。

如果要录制携有多层伴音的信号，需要通过【Setings】→【Record】， 进入录制设置界面（图21），勾选其中的“Record all audio streams”录制所有的音频流即可。

例如我们要录制70.5°E欧星W5卫星上采用七层伴音的欧洲新闻台（11306 V 27500），点击左边的【Record】项目键，在弹出一个录制设置界面中（图22），可以看到视频PID码和七层伴音的PID码和语言注解，你可以选择全部录制或挑选其中的几个伴音进行录制，也可以去掉视频PID码的选择，只录制伴音信号。

AltDVB软件录制信号文件采用TS格式封装，你可以通过电脑中VLC media player（VLC）、Windows Media Player（WMP）、Media Player Classic（MPC）、KMPlayer等多媒体播放软件直接播放，图23为采用VLC软件播放时的音频轨道选择界面，同样可进行多层伴音的选择播放。

对于AltDVB软件录制的信号文件，你还可以采用现今流行的DM500S卫星多媒体接收机硬解压播放，如图24所示，并且能够通过遥控器上的AUDIO音频键进行伴音选择播放，详细方法我们将从明年的第1期开始陆续介绍，敬请关注。

2、高清信号的录制和播放

一些硬件配置较低的电脑，采用AltDVB软件自身提供的DVB音视频解码插件，将不能播放70.5°E卫星上的 Luxe TV免费高清信号，不过AltDVB软件可以将它录制下来，再用其它多媒体软件播放。图25为录制Luxe TV高清信号的界面，其中界面的右下部区域有录制信息显示和录制指示。

对于高清信号的播放，需要相应的解码引擎。最简单的方法是从网络上下载一款名为“终极解码”的全能型解码包，它自带MPC、KMP、BSP三种流行播放软件，并对WMP提供良好的支持，可在简、繁、英三种语言平台下实现各种流行音视频的完美回放及编码功能。我们采用MPC播放软件，播放Luxe TV高清信号画面如图26所示。

对于Luxe TV高清信号的格式，可以通过【播放】→【滤镜】→【Mpeg Splitter】→【属性】进行查询，如图27所示。

从图中得知，Luxe TV高清信号的视频采用MPEG4 Video（H264）编码格式，分辨率为1280×1080，宽高比约为20:17，MPC播放软件所调用是解码引擎为Cyberlink H.264/AVC Decoder。

实际上AltDVB软件具有播放信号的信息显示功能，在其播放画面的上方能够该播放信号的视频、音频格式显示，虽然我们这台电脑可能是配置较低（配置：845PE主板、P42.4G的CPU、DDR512M内存、nVIDIA FX 5200显卡）而不能播放Luxe TV高清信号，但通过界面左边、下面的扩展/隐藏按钮，将画面扩展到最大（图28）从黑屏的上方仍然能够看出该信号的视频、音频格式信息。

和Luxe TV同在一个转发器下的中国移动（TERISTIT CHINA）是一个测试频道，该频道是不久前从138°E亚太5号上转过来的，如图29所示，可以看到该信号的视频分辨率为352×576，是一个较为特殊的视频格式，视频码流为1227kbps；音频编码速率为48.0kHz，音频码流为128kbps。

3、同转发器下所有信号的录制和播放

AltDVB软件能够录制同一转发器下的所有信号，也就是转发器全TS流的录制。以录制138°E上的长城（亚洲）卫星直播平台（12537 V 41250）为例，首先播放其中的任意一个信号，如CCTV4频道，在【Record】项目下选择“Whole TS”全TS流项目，弹出一个【FTS Recorder】录制设置界面（图30），在【Stop after】区域内，可对录制的容量大小或录制时间进行预先设定，当录制达到设定的要求时，软件会自动停止录制；最后同样点击“Record”按钮即可录制该信号所在转发器上的所有信号流。

从图31所示录制信息显示可以看出，录制1分19秒，录制总量（Total Size）约为22MB，可见容量是很大的，这因为是录制该转发器下的11个频道的全TS流，录制全TS流文件名称由“年月日时分＋FTS＋下行频率极化”组成。

对于全TS流录制信号的播放，常用的软件是TSReader，具有MPEG-2视频格式码流分析、解码、录制和操作功能，不过这是一个付费的商业软件。对于业余爱好者可以下载一个名为DTVPlayer的自由软件，下载网址为http://www.dvbcn.com/bbs/dispbbs.asp?BoardID=151&ID=18951&replyID=85535&skin=1 ，可能需要注册后才能下载，如果不方便的话，可以进入我们的博客（http://blog.chinatv-net.com/mediablog/user1/symnj/index.htm）下载V1.11版本。

下载完成后，先双击运行install.bat批处理文件，然后双击运行DTVPlayer.exe程序，就可以打开这个DTV多画面播放软件。首先点击【文件】→【添加】，在弹出的打开TS流文件中，查找到我们录制的全TS流文件，再点击“打开”按钮，就可以将TS流载入播放软件中，如图32所示，所有画面都处于播放状态，不过伴音输出为四倍大的画面信号的伴音，至于画面的流畅度，则和你的电脑硬件配置有关。点击左边项目栏的文件展开按钮，出现录制信号选单，可选择其中的任何一个信号进行播放，画面会自动前置于四倍大状态。

TS流录制适用于免费信号，对于能够播放的加密信号，在全TS流录制时，会抛弃解密信息，使得软件无法播放，另外这款自由软件只是一个试用版本，有时间限制。

其它设置

为了1020卡更好地工作，我们还需要对AltDVB软件进行一些设置，点击左边的【Settings】项目键，出现General常规设置界面（图33），勾选其中的“Set last channel on start”和“PowerOff LNB on exit”，这样在每次开机时会自动播放上一次的播放的频道，并且关机时，自动关断室外高频头的供电，节省待机功耗。

应用软件版本控制管理技术研究 篇4

随着信息技术的发展,目前部队指挥信息系统中各指挥终端已不是独立工作,而是网络化、分布式、协同工作。但是对于系统软件和应用软件的安装,目前我们还处在技术人员逐台对指挥终端进行软件部署的阶段。这样就面临着如下问题:(1)难以全面地掌握指挥所本地网络中所有指挥终端的软件安装现状;(2)安装过程中容易因为人员疏忽某步骤或文件导致各种系统故障,难以快速准确地更新各终端的应用软件;(3)当发现问题并解决问题或发布应用软件更新,难以避免机械的重复劳动;(4)安装或更新出问题或软件版本不统一,容易造成终端上应用软件不能正常运行,严重时甚至影响整个指挥系统的正常运行。

由此可见,对指挥信息系统的应用软件版本进行控制管理十分必要。我们对应用软件版本控制管理已进行初步研究,通过研究一套版本控制软件来解决这些问题。

1 版本控制软件设计

1.1 基本功能

版本控制软件应具备以下功能:(1)系统首次安装时,通过某一管理终端对普通席位进行快速发布;(2)当应用程序或配置文件更新时,自动将所要更新的文件及时地发布到各席位;(3)记录应用程序安装、更新版本的历史过程,防止随意修改应用程序版本并为问题回溯提供依据。

1.2 基本组成

版本控制软件由下列4部分组成:版本控制服务器端软件、版本更新服务器端软件、版本更新客户端软件、远程安装发布服务器端软件。其中,应用程序发布服务器端软件运行于Windows平台管理席位,版本更新服务器端软件运行于UNIX服务器,版本更新客户端软件运行于Windows平台普通席位。版本更新客户端软件是随应用程序在系统首次安装时由安装发布服务器端软件安装到各个席位[1]。版本控制软件结构如图1所示。

版本控制软件能够对用户上传的文件(需要将更新的应用程序或配置文件上传到指定的目录中)进行发布和控制,但是对于此外的文件(用户在客户端修改的文件不在服务器指定上传目录中)将不作监控。

版本控制软件工作流程如图2所示,有两种情况。

情况之一:

流程1:服务器端软件定时在局域网内发送广播报文,报文内容由文件更新列表的唯一标识和时间戳组成。

流程2:客户端软件接收到广播报文后,将报文中文件更新列表的唯一标识和时间戳与本地保存的信息进行对比,当两者有所区别时,客户端向服务器端发送报文,请求获得新的更新文件列表。

流程3:服务器端接受请求,并向客户端发出更新文件列表(包括需要更新的文件数量、名称、位置、大小、校验值等信息)。

流程4:客户端经过对比更新文件列表中文件信息与本地对应文件信息,生成实际需要发送的文件列表,并且将列表发送到服务器端。

流程5:服务器接受列表,建立文件发送过程。

情况之二:

客户端软件定时将本地上一次更新的文件列表中的文件与实际文件信息进行对比,当文件信息不一致时,直接进入流程4。

1.2.1 版本控制服务器端软件

版本控制服务器端软件主要完成4个任务:广播更新信息,本地文件管理,客户端管理连接,日志功能。

(1)广播更新信息:定时在指挥所内局域网上广播本地需要更新的文件信息,广播报中内容包括文件列表的唯一标识符和时间戳。当文件有更新的时候,立即开始定时广播报的重新计时,并发出包含新内容的广播报文。

(2)本地文件管理:对本地指定上传目录中的文件进行定时扫描,一般在第一次扫描后即把文件的名称、大小、位置、CRC校验值等信息记录下来。随后每次扫描都将结果与上次扫描进行对比(对比上面提到的所有信息),如结果一致则等待下次扫描,如结果不一致则重新生成文件信息记录和文件更新列表,并通过广播通知客户端有文件更新。

(3)客户端管理:客户端管理用于响应客户端的各种请求,包括:发送当前更新文件列表;根据客户端的实际情况,准备实际文件发送列表(因为在服务器端,可能只更新了某几个文件),并将这些文件发送到客户端。

(4)日志功能:日志功能主要记录以下信息:服务器端每次文件更新的时间、文件名称、文件大小、文件校验值、文件位置等信息。客户端更新文件的历史记录包括客户端地址、更新时间、文件名称、文件大小、文件校验值、文件位置等信息。

1.2.2 版本更新服务器端软件

版本更新服务器端软件由本地文件处理、过程记录、客户端管理、前台服务组成,如图3所示。

图3版本更新服务器端软件组成

本地文件处理主要完成下面的任务:

(1)定时扫描指定的上传目录,通过递归扫描的方式,将文件的位置、文件的名称记录下来。在扫描的同时计算出这些文件的大小和CRC校验值。因此用户如果需要更新软件或配置文件,就需要按原目录路径将应用程序和配置文件上传到指定的上传目录。

(2)将用户上传的文件同本软件工作目录中的文件进行比较,看是否有更新的文件和新加入的文件。如果有则通知“前台服务”,由“前台服务”通知各客户端更新文件并且如果当前有正在更新的任务,则停止;如果没有文件更新,则删除上传目录中的文件。

(3)将所有操作通知“过程记录”,由“过程记录”形成日志文件。

1.2.3 版本控制客户端软件

版本控制客户端软件主要是完成本地文件管理和日志功能。

(1)本地文件管理:将接收到由服务器发送的更新文件列表中的文件信息与本地对应的文件进行比较,如果结果不一致则向服务器发送更新文件请求,准备更新文件。每次更新文件前,保存上一次更新的文件。当更新版本出现问题的时候,方便用户进行回滚操作[2,3]。

(2)日志功能:记录每次更新的过程[4],并保存每次更新的时间,文件名称、文件大小、文件校验值、文件位置等信息。

1.2.4 远程安装软件

该软件只有服务器端,客户端不需要安装代理程序。远程安装软件完成两个功能:客户端管理、软件安装。

(1)客户端管理:自动完成本地局域网计算机的搜索或由用户指定扫描某网段计算机,将搜索到的计算机列表保存下来;由于远程安装需要远程计算机的超级用户密码,所以对于用户指定安装的计算机保存其密码,对远程计算机进行管理[5];保存客户端安装软件的历史记录。

(2)软件安装:用户通过选择要安装的软件包,和指定要安装的一台或多台计算机,开始安装程序。对完成安装任务的计算机,交客户端管理部分记录其状态。

2 技术验证

首先用版本控制服务器端软件安装客户端软件,如图4所示(该图为客户端管理界面,显示搜索到的计算机列表),安装完成会有客户端安装成功提示,如图5所示(在安装的客户端机器上看到的客户端软件启动信息),客户端软件已启动运行。

向客户端配置项目管理,即确定需要监视管理的目录以及其中的具体文件,如图6所示。

版本改变提示,当被监视的目录中有文件修改或删除时会给出提示。将IP地址为“7.96.32.24”的客户端即“kjb-zz”的test目录中的gw.cpp文件修改,出现如图7所示界面(客户端监视目录有变化提示)。

3 结束语

文章分析了当前指挥信息系统的特点,研究了相适应的软件版本控制管理软件,针对当前指挥终端进行软件部署的方式进行了改进,能够显著提高软件部署效率及准确性。目前我们对指挥信息应用软件版本控制管理技术的研究已经进入初步使用阶段,还未正式投入使用。应用软件版本控制管理技术在实际系统使用过程中需要系统用户的密切配合。

参考文献

[1]于晓明,网络控制系统控制策略研究[D].杭州:浙江大学,2013.

[2]徐文聪,徐慧,羊帅.基于消息中间件的远程医疗监护技术[J].指挥信息系统与技术,2014(01):52-57,62.

[3]Jon L,Matthew M.Git版本控制管理[M].北京:人民邮电出版社,2015.

[4]斯威司古德.版本控制之道[M].北京:电子工业出版社,2010.

软件版本 篇5

（例：车辆诊断仪的标定软件配置管理系统及方法）

发明背景技术

（说明与本专利申请技术方案最接近的现有技术或产品，描述现有技术或产品的主要结构及原理，并指出该现有技术或产品存在的缺点或不足之处。如果方便的话可以提供现有技术的附图）

随着汽车电子技术的飞速发展，车辆的功能复杂性日益提高，安全、环保、节能方面的法规要求日益严格，舒适、灵活、个性化的客户需求千差万别，市场竞争全球化，使开发周期不断缩短，大量的电子控制器在汽车中广泛使用，导致车辆的诊断仪开发面临巨大挑战。

汽车在在开发过程中，需要根据目标市场要求、法规要求、车型配置要求等对控制器进行整车标定。例如发动机控制器、空调控制器、车身防盗控制器、自动变速器控制器、车身稳定控制系统（DSC）控制器、刹车防抱死系统（ABS）控制器、仪表控制单元等。

汽车进入市场后，针对法规的要求的变化，发现的问题和市场中客户的反馈，对各控制器进行重新配置和标定。在售后的维修保养中，同种车型的控制系统，会有不同的零件配置，需要不同的标定软件进行刷新。

在车辆诊断和标定软件刷新过程中通常使用诊断仪，当需要更新车辆控制器标定软件时，通过诊断仪的通讯接口与车辆诊断接口连接，例如SAE（美国汽车工程师学会）J1962标准接口，将新的标定软件刷新到车辆的相应控制器中。由于车辆功能日益复杂、车型众多、控制器日益增多，传统的标定软件刷新方法不但容易出错，而且效率低下。

具体的技术方案描述及本发明的有益效果

（请结合附图清楚、完整地描述本发明的技术方案，说明本专利的原理、工艺过程等，使本领域的普通技术人员人能够不需要创造性的劳动就可以理解/实现本

发明。同时提交本发明的有益效果。）

请参阅图1，本发明揭示了一种车辆诊断仪的标定软件配置管理系统，该系统与车辆诊断仪通信，所述系统包括配置数据库

11、及分别与所述配置数据库11连接的标定软件库

12、控制器格式文件

14、配置报告

15、标定加密软件包16。

所述配置数据库11用以维护各个车型的控制器信息13，该控制器信息13至少包括零件编号结构、车型的配置信息，所述零件编号结构包括总成号、硬件号、软件号、网络号、标定号；优选地，所述零件编号结构还包括零件的配置特征值、特殊配置的传感器、特殊配置的执行器、特殊配置的目标市场。所述配置信息包括起止车辆识别号、EOBD、年份车型、日期、所配置的硬件信息。所述配置数据库11还用以维护零件编号结构的可用性、发布状态，同时维护零件软件与网络软件的兼容性。

所述控制器格式文件14用以对各控制器信息进行设定。所述配置报告15用于对车辆诊断仪所诊断的车辆控制器、及其标定软件是否需要更新进行判断。所述标定软件库12用以存储所述车辆诊断仪所需的应用软件、标定软件、网络软件。所述标定软件库12还设置所述配置数据库中零件编号结构与该标定加密软件包的链接。所述标定加密软件包16包含对控制器所需要的应用软件、标定软件、网络软件加密，把所述配置报告15分别发送给车辆诊断仪，更新车辆诊断仪。

车辆诊断仪接收配置报告

15、标定加密软件包16，读取车辆的控制器信息，根据所述配置数据库、配置报告进行判断、抽取合适的标定软件，对车辆进行刷新。配置报告为上述应用软件、标定软件、网络软件的配置说明。所述车辆诊断仪生成配置管理报告的同时，还从所述控制器标定软件库中提取需更新的软件，更新标定加密软件包，该标定加密软件包用于更新车辆诊断仪。

请参阅图2，以下结合图2介绍一种利用上述系统的标定软件配置管理方法，包括如下步骤：

步骤0、任意车型或控制器更新；标定软件库更新标定软件。

步骤

1、提供一配置数据库，该配置数据库维护控制器零件信息和文件库，并将软件库加密打包，存入软件库。所述控制器零件信息至少包括零件编号结构，该编号结构包括总成号、硬件号、软件号、网络号。

步骤

2、打包软件库发送给维修站，更新诊断仪。

步骤

3、获取被诊断车辆控制器的硬件号，该硬件号对应该车型的控制器信息；同时获取车辆的特征键、车辆识别码，查询控制器配置报告，上述特征键包括控制器的所有特征。

步骤

4、根据被诊断车辆控制器的硬件号，查询控制器配置报告。步骤

5、判断被诊断车辆软件版本是否需要更新；若需要，执行步骤6，否则转向步骤10。

步骤

6、从标定加密软件包中，提取需要更新的软件。步骤

7、用步骤6中所提取的软件刷新被诊断车辆的控制器。步骤

8、更新控制器特征键和零件信息。

步骤

9、生成被诊断车辆的控制器的数据库完整性报告。步骤

10、结束。

本发明的有益效果在于：本发明通过更新车辆诊断仪控制器的软件库来更新诊断仪控制器，能够进行统一高效地管理，提高了更新控制器配置的灵活性、完整性、严密性和诊断效率。适应了车辆发展的未来需求，可持续对复杂程度日益增长的车辆的控制器进行完整、快速地配置。

附图

最好附可以编辑的附图，不要有色彩、阴影，只要线条勾勒的示意图即可。

12控制器标定软件库软件库13控制器信息维护14控制器格式文件库文件配置管理数据库11控制器配置报告15软件加密包16

图1（本发明车辆诊断仪的标定软件配置管理系统的组成示意图）

任意车型或控制器更新配置管理数据库维护控制器零件资料和文件库，并将软件库加密打包，存入软件库打包软件库发送给维修站，更新诊断仪读取车辆的特征键和控制器信息查询配置报告40123控制器软件版本是最新且完整吗?5否从软件库提取软件6刷新和配置控制器更新车辆的特征键和控制器信息数据完整性报告10978是结束