软件状态管理（精选九篇）
软件状态管理 篇1
目前国内军用嵌入式软件研制相关单位对硬件技术状态管理主要依据GJB3206A -2010 《 技术状态管理 》 ( 其中GJB3206A-2010 中明确说明软件按照GJB5235-2004 《军用软件配置管理》进行管理) , 目前军用嵌入式软件研制相关单位对软件技术状态管理主要依据GJB5235 -2004。 其中Configuration Management被翻译为技术状态管理 (用于硬件技术状态管理) 和配置管理 (用于软件技术状态管理) 。因此, 从本质上说, 两个标准的含义是一样的, 只是翻译的不同。鉴于软件属于系统的一部分, 因此在软件研制的过程中, 可以借鉴硬件技术状态管理的相关要求并应用到软件配置管理过程中, 并最终达到两者融合, 以一个标准的形式对软硬件技术状态进行管理 (目前国内基本上没有两者融合的相关文章) 。
1 技术状态管理与软件配置管理基本概念解读
(一) Configuration
Configuration在相关标准中的定义为:
(1) 在MIL-STD-2549 中被翻译为技术状态。 现有或计划产品, 或产品组合的特性、功能和物理属性;
(2) 在GB/T 11457-2006 中:在配置管理中, 在技术文档中制定的并在产品中体现的硬件、软件的功能和 (或) 物理特性;
(3) 在GJB3206A-2010 中, 被翻译为技术状态。 在技术文件中规定的并且在产品中达到的功能特性和物理特性;
(4) 在GJB5235-2004 中, 被翻译为配置。 在软件生存周期中各阶段产生的各种形式和各种版本的文档、程序、数据和环境的集合。
在GJB5000A-2008《军用软件研制能力成熟度模型》中指定每个配置项的重要特性主要指的是作者、 文档或文件的类型、以及软件代码、文件的编程语言等。
通过GJB5000A对配置项重要特性的描述, 我们可以将这些重要特性定为软件的物理特性。 也就是说, 软件是有功能特性和物理特性的。
鉴于GJB5235 引用了GB/T 11457, 因此在软件配置管理中对Configuration的定义应参照MIL-STD-2549、GJB3206A或GB/T 11457 的定义较合适。
(二) Configuration management (CM)
Configuration management (CM) 在相关标准中的定义为:
(1) 在MIL-STD-2549 中, 被翻译为技术状态管理。 建立并维持产品特性、功能和物理属性一致性的管理过程;
(2) 在GB/T 11457-2006 中被定义为: 应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征, 控制这些特征的变更, 记录和报告变更处理和实现状态并验证与规定的需求的遵循性;
(3) 在GJB3206A中, 被翻译为技术状态管理。 在产品寿命周期内, 为确立和维持产品的功能特性、物理特性与产品需求、技术状态文件规定保持一致的管理活动;
(4) 在GJB5235 中, 被翻译为配置管理。 为保证软件配置项的完整性和正确性, 在整个软件生存周期内应用配置管理的过程;
GJB5235 中对配置管理定义的最后使用了" 应用配置管理" 这几个字, 其并未说明配置管理具体指什么, 该标准对Configuration management的定义是不准确的。 因此, Configuration management在软件中的定义采用GB/T 11457-2006 或GJB3206A等的定义比较妥当。
(三) Configuration item (CI)
Configuration item (CI) 在相关标准中的定义为:
(1) 在MIL-STD-2549 中, 被翻译为技术状态项。 技术状态项是指为单独的技术状态管理所指派的、能满足某一最终功能的任何硬件、软件或两者的组合;
(2) 在GB/T11457 中, 被定义为配置管理设计的硬件、软件或两者的集合, 它在配置管理过程中作为一单个实体来对待;
(3) 在GJB3206A中, 被翻译为技术状态项。 能满足最终使用功能, 并被指定作为单个实体进行技术状态管理的硬件、软件或其集合体;
(4) 在GJB5235 中, 被翻译为配置项。 为了配置管理的目的而作为一个单位来看待的软件成分, 通常为软件配置中的一个元素。
在GJB5000A中, 工作产品的配置管理可按多个粒度级实施。配置项可以分为配置部件和配置单元。适时可解释为"配置部件"和"配置单元"。
从以上几个概念对Configuration item的解释, 再结合对Configuration的解释, 在软件中使用MIL -STD -2549、GB/T11457、GJB3206A的定义来描述Configuration item比较合适。
(四) Baseline
Baseline在相关标准中的定义为:
(1) 在GB/T11457 中基线 (baseline) 的概念为业已经过正式审核与同意, 可用作下一步开发的基础, 并且只有通过正式的修改管理过程方能加以修改的规格说明或产品。其中功能基线的概念为:在配置管理中, 一配置项的初始批准的技术文档, 相对于分配基线、开发基线、产品基线;分配基线的概念为在配置管理中, 初始批准的规格说明, 它支配作为较高级配置项的一部分的配置项的开发, 相对于开发配置、功能基线、产品基线;产品基线的概念为在配置管理中, 在它的生存周期的生产、操作、维护和后期支持期间, 定义一配置项的初始的经批准的技术文档 (对于软件, 包括源代码清单) 。
(2) 在GJB3206A中, 技术状态基线 (configuration baseline) 的概念为在产品寿命周期内的某一特定时刻, 被正式确认并作为今后研制生产、使用保障活动基准, 以及技术状态改变判定基准的技术状态文件。 一般包括三种技术状态基线:功能基线 (经正式确认的功能技术状态文件) 、分配基线 (经正式确认的分配技术状态文件) 和产品基线 (经正式确认的产品技术状态文件) ;
鉴于嵌入式软件属于整个产品的一部分, 因此从系统融合、控制和易用的角度看, 可以只保留技术状态管理概念上基线的概念:即功能基线、分配基线和产品基线, 将软件配置管理中的功能基线修改为任务基线 (主要包含软件研制任务书) 、分配基线修改为需求基线 (主要包含软件需求规格说明) , 将配置管理中产品基线的内容合并到技术状态管理概念上产品基线中。即系统分配基线包含软件任务基线、需求基线的内容, 产品基线包含软件任务基线、 分配基线和其他软件技术状态项文件。
(五) Configuration identification
Configuration identification在相关标准中的定义:
(1) 在MIL-STD-2549 中, 被翻译为技术状态标识。 与CI的选用、 每个CI必需的技术状态文件类型的确定、CI发布号与其它附属于CI和定义其技术状态的技术文件的标识符、CI的发放和与其关联的技术状态文件, 以及技术状态基线的建立有关的技术状态管理要素;
(2) 在GB/T11457 中, 被翻译为配置标识。 配置管理的元素, 它由为系统选择配置项并在技术文档中记录它们的功能和物理特征组成;
(3) 在GJB3206A中, 被翻译为技术状态标识。 确定技术状态项及其所需技术状态文件, 标识技术状态项及其技术状态文件, 发放和保持技术状态文件, 建立技术状态基线的活动。
两个标准中概念基本一样。
(六) Configuration control
Configuration control在相关标准中的定义为:
(1) 在MIL-STD-2549 中, 被翻译为技术状态控制。 在某一CI的配置中, 有关系统的建议、 判断、 评估、 协调、 建议更改的处置, 以及所有批准/发放的更改实施的技术状态控制要素;
(2) 在GB/T11457 中, 被翻译为配置控制。 配置管理的元素, 它由评价、协调、批准或不批准和在配置项的配置标识正式建立以后, 配置项变更的实现组成;
(3) 在GJB3206A中, 被翻译为技术状态控制。 技术状态基线建立后, 对提出的技术状态更改申请、偏离许可申请和让步申请所进行的论证、评定、协调、审批和实施活动。
两个标准中对该概念解释基本一样。
(七) Engineering Change
Engineering Change在相关标准中的定义为:
(1) 在MIL-STD-2549 中被翻译为工程更改。 对某个技术状态项的现行已批准技术状态文档的更改;
(2) 在GB/T11457 中被翻译为工程更改。 在配置管理中, 配置项或其他指定的项在正式建立它的配置标识后在配置中的变更;
(3) 在GJB3206-1998 中原术语为工程更改, 在GJB3206A中术语被修改为技术状态更改。 在产品寿命周期内, 对已正式确认的现行技术状态所做的更改。
两者概念基本一致。
(八) Configuration status accounting
Configuration status accounting在相关标准中的定义为:
(1) 在MIL-STD-2549 中被翻译为技术状态的状况记实。有关获得、 存储和授权使用技术状态信息的技术状态管理活动, 这些技术状态信息是有效管理产品和产品信息所必需的;
(2) 在GB/T11457 中被翻译为配置状态记录。 一种配置管理的元素, 它由记录和报告为有效地管理某一配置所需的信息组成。 此信息包括列出经批准的配置标识表、建议变更的配置状态和经批准变更的实现状态;
(3) 在GJB3206A中被翻译为技术状态记实。 在产品寿命周期内, 为说明产品的技术状态所进行的记录、报告活动。
两者概念基本一致。
(九) Configuration audit
Configuration audit在相关标准中的定义为:
(1) 在MIL-STD-2549 中被翻译为技术状态审核, 见功能技术状态审核和物理技术状态审核;
(2) 在GB/T11457 中被翻译为配置审核。 对所要求的全部配置项均已产生出来, 当前的配置与规定的需求相符所作的证明;
(3) 在GJB3206A中被翻译为技术状态审核。 为确定技术状态项与其技术状态文件的一致程度而进行的正式检查。包括功能技术状态审核和物理技术状态审核。
两者概念基本一致。
(十) Functional configuration audit
Functional configuration audit在相关标准中的定义为:
(1) 在MIL-STD-2549 中, 被翻译功能技术状态审核。 为了验证项目已经达到其功能和/或分配技术状态文件中规定的要求, 在设计能力、专用工装或研制试验验收之前, 对系统或某一技术状态项的功能特性的正式检查;
(2) 在GB/T11457 中被翻译为功能配置审核。 一种审核, 它指导验证:配置项的开发已经满意完成、配置项已达到在功能的或分配的配置标识中规定的性能和功能特征并且它的操作的和支持的文档已满意地完成;
(3) 在GJB3206A中被翻译功能技术状态审核。 为验证技术状态项的功能特性达到功能基线、分配基线规定的要求所进行的技术状态审核。
两者概念基本一致。
(十一) Physical configuration audit
Physical configuration audit在相关标准中定义为:
(1) 在MIL-STD-2549 中被翻译为物理技术状态审核。 根据技术文档对技术状态项的"即成"技术状态进行的正式检查, 以建立或证实该技术状态项的产品基线;
(2) 在GB/T11457 中被翻译为物理配置审核。 验证已建立的某个配置项遵循定义它的技术文档的审核行为;
(3) 在GJB3206A中被翻译为物理技术状态审核。 为建立或验证产品基线, 对技术状态项试制试产样品的完工状态、所依据的技术状态文件而进行的技术状态审核。
对于软件研制过程中的物理配置审核, 目前通用的做法是检查是否文文一致、文实相符、是否可用等。而在系统研制的过程中, 对系统技术状态文件的审核过程中也会检查文文一致、文实相符、是否可用等内容。因此从软硬件系统融合的角度, 可以删除软件配置管理过程中物理配置审核的概念, 只需将这些实际工作体现到日常工作中即可, 在系统产品基线建立之前/后对整个系统 (包含软件) 进行物理技术状态审核。
(十二) 配置管理审核 (CMA)
在GJB5000A中对配置管理审核的描述为:目的是确认配置状态记录和配置项是否完备、一致和准确。
但在日常的系统技术状态审查或检查等中进行的就是软件配置管理审核的工作。 因此可以删除此概念, 直接用技术状态审核的概念即可, 以便达到两者的融合。
(十三) 配置库
(1) Product library
Product library在相关标准中定义为:
(1) 在GB/T11457 中被翻译为产品库。 一种软件库, 其中含有已被批准供当前运行使用的软件;
(2) 在GJB5716 中对产品库的定义为在软件生存周期中, 存放已定型 (鉴定) 且供交付、生产、检验验收的软件配置项的集合。
(2) Software development library
Software development library在相关标准中定义为:
(1) 在GB/T11457 中被翻译为软件开发库。存放与软件开发工作有关的计算机可读信息和人们可读信息的软件库。
(2) 在GJB5716 中对开发库的定义为在软件生存周期中, 存放软件配置项的集合。
(3) Software controlled library
在GJB5716 中被翻译为软件受控库。 在软件生存周期中, 存放已通过测试或评审且作为阶段性产品的软件配置项的集合。
从以上三点可以看出:
(1) 按照国标的定义, 在软件配置管理过程中, 有开发库的定义;
(2) 按照国标的定义, 在软件配置管理过程中, 有产品库的定义 (其中该产品库包含GJB5716 的受控库) ;
(3) 软件配置管理过程设置2 个库 (或者3 个库等) 是从使用的目的出发而增加了控制时机的存储库, 因此在实际的软件技术状态管理过程中, 即使是一个库, 如果增加了相应的控制时机, 也是可以的。
(十四) 概念解读小结
通过以上概念解读, 从军用产品系统技术状态控制的角度出发, 硬件技术状态管理和软件配置管理相关概念与做法在本质上是一致的, 因此我们不应人为将软件配置管理从大系统的技术状态管理中分割出去, 我们应在标准编制和实践过程中将两者融合统一, 避免在错误的路线上越走越远。
为了方面进行描述, 以下内容统一软硬件技术状态管理相关概念:
(1) 统称为技术状态管理;
(2) 统称为技术状态项, 技术状态项由技术状态文件和技术文件构成;
(3) 统称为技术状态标识;
(4) 统称为技术状态控制;
(5) 统称为技术状态记实;
(6) 统称为技术状态审核。
2 软件技术状态管理中存在问题与解决思路
(1) 技术状态项的选择
目前军工行业及相关行业大多数单位, 在选择软件技术状态项时, 将软件技术状态文件和技术文件选取为技术状态项, 没有从系统的角度选取配置项, 导致软件技术状态管理与硬件技术状态管理脱节。 造成该现象的主要原因为:硬件技术状态管理主要依据GJB3206A-2010 《技术状态管理》, 软件按照GJB5235-2004《军用软件配置管理 》进行技术状态管理。
因此我们应该将硬件技术状态管理相关标准和软件技术状态管理相关标准融合统一, 避免相关单位在软件技术状态项的选取上犯错误, 导致不必要的麻烦。
(2) 技术状态项标识
目前军工行业及相关行业大多数单位, 在对软件技术状态文件或技术文件进行标识 (特别是对文档进行标识) 时, 往往同时存在着标准化管理部门提供的文档编号及版本号、配置管理部门提供的配置标识及版本号, 导致软件技术状态项的标识不唯一。因此需要从大系统技术状态项标识的角度融合这两个部门提供的标识号, 确保唯一。
(3) 软件技术状态控制
目前军工行业及相关行业大多数单位, 制定了软件入库控制、出库控制以及更改控制相关要求。 但往往对入库与出库控制太严, 忽略了最应重视的更改控制, 且更改控制级别等划分较粗, 同时还存在着重复办理更改手续 (如在软件配置管理业务中办理一次更改, 在大系统技术状态管理过程中对软件文档又办理一次更改) , 软件技术文档的源头不唯一 (同时采用软件配置管理工具 (如Clear CaseSVN等) 和产品数据管理工具 (如西门子公司的Team Center) 对软件文档进行管理) 等问题。
(4) 软件更改等级划分建议
可以从以下方面对软件更改进行控制, 划分软件等级:
(1) 对属于系统分配基线、产品基线的技术状态文件 (如软件研制任务书、软件需求规格说明) 的功能、性能、接口等的更改定为I类更改, 对不属于系统分配基线的技术状态文件 (如软件设计说明) 或产品基线中非功能、性能、接口等的更改定为II类更改, 对不属于技术状态文件的技术文件及属于技术状态文件的其他更改定为III类更改 (如过程域中支持过程、项目管理过程产生的软件开发计划、软件配置管理计划、软件质量保证计划等) 。
(2) 在更改级别的划分中还可以考虑系统所处阶段 (如初样阶段、试样阶段等) 、状态、主干与分支等情况。
(5) 软件技术状态更改重复审批改进建议
对于重复办理更改手续的问题, 原因是相关单位未意识到软件配置管理相关国军标作用下的技术状态更改与大系统技术状态相关国军标作用下的技术状态更改是同一个概念, 从而导致重复办理更改手续的问题。因此需要重新梳理整合更改流程, 确保软件技术状态更改流程只有一个。
(6) 软件技术文件源头不唯一改进建议
软件作为产品的一部分, 采用产品数据管理工具对其进行状态进行管理从本质上没有错, 但目前业界内很多单位同时使用配置管理工具和产品数据管理工具对文档进行管理, 导致软件技术状态不唯一。 因此应控制软件的源头, 可以以配置管理工具作为源头, 当软件技术状态固化之后, 将软件文档等传递到产品数据管理系统中, 以保证产品数据的齐套性;或者直接以产品数据管理系统等工具直接管理光、机、电、软的相关技术文件。
3 软件技术状态管理发展趋势
软件作为系统中的一部分, 其技术状态管理从长远来看, 将与硬件技术状态管理融合统一 (对于以上概念解读中不互相冲突的, 在此不再进行描述) :
(1) 软硬件技术状态标识的融合;
在整个系统中, 整合标准化部门提供的文档编号和软件配置管理部门提供的配置标识, 确保软件技术状态项具有唯一标识, 并将其标识增加部分标识符之后扩展到技术状态文件和技术文件。
(2) 软件三库不再是传统意义上的三库, 是软硬件综合大系统层次上的三库, 且三库数据源唯一;
如在嵌入式产品设计平台中将通过正式评审之前 (如审查、配置项测试前) 的内容作为开发库进行控制, 只需要在平台中记录软件需求更动历史信息, 没有必要专门使用配置管理工具作为开发库;将通过正式评审或配置项测试后的技术状态文件存放在嵌入式产品平台的"受控库" (可以是加了相关标记的受控库, 不一定是严格意义上的传统受控库) 中进行管理, 对于非技术状态文件 (如软件计划类文档) 可以只进行开发库级管理;软件设计定型后, 将技术状态文件纳入产品库管理 (该产品库内容一定属于档案管理部门管理内容的一部分, 产品库也可以同时是档案库) , 原则上产品库与档案库数据源应唯一。
(3) 软件技术状态更改流程唯一;
应整合软件配置管理标准作用下的软件更改流程与大系统技术状态标准作用下的更改流程, 确保软件技术状态更改流程唯一。
(4) 软件设计定型后, 将以发放的形式代替目前的出库审批形式供生产现场使用;
目前相关软件国军标中明确规定了软件设计定型后需要办理软件出库手续从产品库中提取软件, 这增加了部分管理成本, 因此最好的方法是借用大系统技术状态管理标准下的发放方式 (目前软件采用发放的方式还暂时不被顾客代表等认可) , 以提高效率。
(5) 软件技术状态审核的融合;
在软件设计定型之前, 从大系统技术状态审核角度, 对整个产品进行审核时, 软件与整个产品一起事件或定期进行功能技术状态审核 (可以结合评审、测试、专项检查等方式) 。
在产品基线建立之前或为了验证产品基线, 软件随系统进行物理技术状态审核 (可以通过评审、验收、靶场等方式进行) 。日常情况下, 软件与大系统一起做好软件技术文件产生、存储、使用、废弃及销毁过程中物理配置管理审核 (即文文一致、文实相符、是否可用审查等) 。
(6) 基线的融合;
从大系统的角度, 设置系统功能基线、分配基线 (将软件研制任务书、软件需求规格说明纳入到系统分配基线中) 、产品基线 (将软件相关技术状态文件纳入产品基线中) 。取消软件功能基线或改名为任务基线; 取消软件分配基线或改名为需求基线;取消软件产品基线, 使之融合到系统产品基线中。
参考文献
[1]United States Department of Defense.MIL-STD-2549Configuration Management Data Interface[S].
[2]中华人民共和国国家质量监督检验检疫总局, 中国国家标准化管理委员会.GB/T 11457-2006信息技术软件工程术语[S].
[3]中国人民解放军总装备部.GJB3206A-2010技术状态管理[S].
[4]中国人民解放军总装备部.GJB5235-2004军用软件配置管理[S].
[5]中国人民解放军总装备部.GJB5000A-2008军用软件研制能力成熟度模型[S].
软件状态管理 篇2
来源：企业网D1Net发布时间：2010-08-06摘 要：近日，开新换车连锁服务公司选择了奥迪坚IP融合型和分布式呼叫中心平台搭建开新换车连锁热线，为客户提供7*24小时的换车咨询服务
近日，开新换车连锁服务公司选择了奥迪坚IP融合型和分布式呼叫中心平台搭建开新换车连锁热线，为客户提供7*24小时的换车咨询服务。本次开新汽车采用了奥迪坚最新推出的MAXCS系统，其中的班长席训导功能和大屏显示软件2项技术特色尤为突出。
呼叫中心大屏幕实时显示系统如何用？就是提供呼叫中心单个或多个工作组的实时队列状态、实时工作组资源状态、每日工作绩效以及一段时间内的数据趋势等实时数据的显示，并通过大屏幕显示在呼叫中心显著位置，帮助呼叫中心运营管理人员实时监控呼叫中心运营状态，及时调整各技能组人员投入，保证座席的高效利用和服务质量。
而谈到MAXCS，那是Max Communication Server的简称，是奥迪坚全新的IP分布式呼叫中心产品，拥有硬件处理和软件处理兼容的双媒体处理机制，高智能的IP接入网关可以在接入层进行一定的语音处理工作，从而减少了对网络带宽资源的占用以及HMCP媒体服务层和核心交换层的工作量。
同时，当任一接入网关发生故障时，不会影响到整个系统平台的运行。高融合性的单点又可组成分布式的多点，各点既可独立运行，又可统一管理。这些正是MAXCS有别与其他呼叫中心的地方。
事实上，MaxInSight大屏显示软件，是奥迪坚MAXCS产品系列中一个工作组状态显示程序。它可以通过挂壁式的LCD大屏或PC电脑显示屏来实时显示工作组的工作状态和运行数据，以供呼叫中心的管理员和座席参考。他可以显示单个或多个工作组的实时队列状态、实时工作组资源状态、每日工作绩效以及一段时间内的数据趋势。同时MaxInSight软件还配备了很多个性化的功能，将坐席工作变得更加丰富多彩。
海上平台三维模型状态管理研究 篇3
关键词：三维模型；数据库；状态管理
中图分类号：P208 文献标识码：A 文章编号：1006-8937（2014）9-0043-01
数据库模型管理在某种程度上来说是对整个工程项目的把控起到至关重要的作用。从以往的工程来看，三维模型都会出现由于各种主观和客观原因协调不到位，导致与实际项目环境不符，直接影响后期加工安装制作等问题。
1 三维模型设计现状分析
海上平台引入三维模型设计系统管理，发展的现状从客观来看，由于设计周期短，设备参数未及时到位等重要因素影响三维模型的设计；从主观上来看，一个平台，各专业种类繁多，各专业之间和专业内部不是所有的问题都能及时反馈、协调和调整，导致后期数据库和模型布置等修改量比较大；另外，设计人员的技术水平不同也是主观因素的一部分。就项目而言，从整个项目周期来看项目部反馈的意见，分析得出多数的问题都是由于主观原因造成的。当然，无可否认的是，在项目前期，客观占主导因素，但客观因素影响非主要因素，主要是主观因素。
1.1 详细设计
平台三维模型设计主要在项目的详细设计阶段，经过30%审查（所有设备和管线需要建立模型和完成大概的布置）、60%审查（所有设备模型参数和管线布置接口需要准确）、90%审查（所有设备模型参数和管线布置需要最优化）后，方可提交给下一阶段，即加工设计阶段。在详细设计阶段期间，各专业和专业内部交叉影响比较大。
①首先，各专业之间在同时段输入模型数据并完成布置，在设计流程中，专业之间的接口信息比较少，设计人员更多从自身专业出发，在模型数据修改和布置上都按照本专业系统要求完成。由于不了解其他专业的系统特点，可能考虑去修改外专业的模型数据。更多会忽略专业之间的接口信息。这种影响尤其在30%审查阶段比较突出；
②各专业之间在模型数据库上都有统一的权限，可以对任意模型进行修改和布置，一般来说，在30%～60%审查阶段比较少考虑其他专业的因素；
③在模型和数据库管理上，专业内部没有分权重比例，设计、校核、审核和批准都在同一个模型管理条件下进行。虽然模型和数据库控制自由度比较大，但也因此模型和数据库得不到有效管理；
④在详细设计阶段，从实际意义上来说并没有分状态，而且无法有效追踪到模型修改的作者、时间和日期。由于客观因素的影响，可能人为地修改模型和数据库，需要找到修改的原因和目的，并非易事。对于设计人员来说，随着工期推移，本身也未必记得当时修改内容。
1.2 加工设计
在完成详细设计后，进入加工设计阶段，此阶段与安装建造阶段同步。在加工设计阶段过程中，很多相关的模型在实际环境安装过程中，与图纸不符，原因可能忽略了一个就是安装偏差，另外一个是加工偏差。实际上，详细设计后期已根据模型大量出版相关设备清单和管线图纸，模型中并未考虑加工余量和安装偏差余量，在设计过程中，甚至模型之间的相对位移精度比较高，这也增加了加工设计的难度。
2 优化模型管理
研究一种模型管理方式——状态管理（MMSSTATUS），其實在PDMS上已有该属性，在这基础上加以二次开发，可以实现模型控制管理。当然，根据这个平台系统设计，这个属性只能控制在branch层以上，同理，在设备、结构、电气、仪表等专业上也只能管理控制相同层以上。同时，在不同专业领域和专业内部设置不同的模型数据库的修改和调用的权限声明。这样优化的特点：
①可以避免交叉专业的影响，不同专业不能修改本专业外模型数据库。涉及到外专业的交叉影响部分，需要跟外专业及时进行沟通，相互交叉影响的专业，适时修改和调整影响部分；
②专业内部在权限声明时，其实需要修改的内容已与上一级沟通协调。这样就可以避免因某个人主观意见去判断修改该影响部分；
③由于模型受到管理和控制的因素，在模型数据库更新时，只能由power user去更新相关的元件库。这样做的目的就可以把受影响部分，有条理有步骤地进行分专业进行调整和修改。
2.1 状态管理
在详细设计阶段，引入模型数据库状态管理，将状态（MMSSTATUS）管理分为如下说明等级：
①状态unset表示该模型没有任何属性输入或者模型滞留（不存在于PID）；
②状态15#表示该模型存在技术问题不能开展设计：blocked by technical problems；
③状态30#表示该模型初步完成详细设计和布置： design on progress；
④状态50#表示该模型虽然完成初步设计，但由于元件缺失导致不能发布：blocked delivery by missing catalogue；
⑤状态60#表示为详细设计完成、初步计算分析受力完成、属性完整、模型与PID一致：delivered to next step design；
⑥状态90#表示该模型具备出图条件，同时具备详细应力分析条件，可以进行加工设计：machining design；
⑦状态95#表示在加工设计阶段，充分考虑各种偏差，模型与实际不符：blocked by deviation。
注意：状态声明可以由最初的设计人员更新，但只能往高调整，往低调整只能是相关获得授权的人员；外专业不能修改和调整本专业的模型和数据库。
3 结 语
状态管理（实际上就是加强分层、分支管理）目前已在其他行业得到很好的应用，比如核电，火电等。海上平台设计在提高工程效率方面，首先应该从细节着手，对输入和输出的模型和数据库实时有效进行管理，减少主观因素对工程设计的影响；在客观方面，应建立起完整的数据库，对于不同项目都有相关的数据库可以调用；其次，在流程管理上，加以细化，特别是详细设计阶段，可以有效的管理和控制整个设计过程。
参考文献：
基于CPN状态空间的软件场景测试 篇4
基于规格说明的测试是指根据规格说明描述的系统行为生成测试用例。软件规格说明包括自然语言、形式化语言、形式化建模等不同方法。学术界和工业界基于规格说明测试研究的关注点在于从规格说明推导出测试用例及可测试性研究等[1,2,3,4]。形式化的模型提供了系统行为的高层描述,基于模型的测试依据描述系统行为的模型来开发测试用例。近年来,随着UML、FSM、CPN等建模技术的大量应用,基于模型的软件测试逐渐受到重视[5,6,7]。
Petri 网起源于Carl Adam Petri的1962年的博士论文[8]。Petri 网是基于图形和数学工具的建模方法,用于描述并发、分布、异步、并行等特征的系统行为。着色Petri 网CPN(Colored Petri Net) 集成了Petri 网和高级编程语言抽象机制的优点,具有形式化的数学定义和精确的语法、语义,提供了描述进程交互的各种原语,为定义和分析不同系统行为属性奠定了基础[9,10,11],已经广泛应用于信息系统建模分析和控制的各个领域,文献[12]提供了完整的CPN形式化定义。在工业实践上,用户可以采用各种CPN建模工具进行建模。由丹麦奥尔胡斯大学开发的CPN tools[13]是一个业界流行的系统建模工具,该工具提供图形化工具方法进行系统行为的建模和分析。
本文提出了基于CPN模型状态空间的测试用例生成方法,国内外学者在这个领域做了很多相关工作。文献[14]提出了利用CPN 模型进行GUI测试用例的生成方法,文献[15]将软件故障树SFT(Software Fault Tree)和CPN 应用到基于Agent的入侵检测系统的规格说明、设计和实现上。文献[16]提出了在测试领域中将UML图转变成CPN模型的方法。
1 CPN 定义及饮料机模型
1.1 CPN定义
CPN中的所有元素均通过严格的规范予以定义,基于CPN的信息系统模型具有清晰性和严格性两方面的特点。为了避免常规Petri 网在实际建模时出现的模型过于庞大,增强建模工具的表达能力,CPN对Petri 网进行了颜色扩展,用于区分不同类型的Token,同时支持守护函数和转换弧的ML函数支持。为了下面讨论的方便,在此按照文献[12]给出CPN的形式化定义。
一个CPN是一个多元组CPN=(∑, P, T, A, N, C, G, E, I),其中:
1) ∑是颜色集,是非空有限集;
2) P是库所的有限集;
3) T是变迁的有限集;
4) A是弧的有限集,P、T、A三者互不相交;
5) N是节点函数,其中 N:A->(T×P∪T×P);
6) C是颜色的集合,其中C: A->∑;
7) G 是哨兵函数,定义为G: T -> Expr 且满足:
∀t∈T:[Type(G(t))=B∧Type(Var(E(a)))⊆∑]
其中:
Type(v)表示变量的类型,
Var(Expr)表示表达式Expr的变量集。
8) E为弧表达式函数,定义为E: A-> Expr 且满足:
∀a∈A:[Type(E(a))=C(p(a))ms∧Type (Var(E(a)))⊆∑]
其中:
p为N(a)中的位置MS;
C(P)表示位于C(p)之上的所有多重集的集合。
9) I是初始化函数,定义为I: P-> Expr 且满足:
∀a∈P:[Type(I(p))=C(p)MS]
1.2 自动饮料机模型
和三角形判断问题一样,自动饮料机是软件测试领域内经典的例子,程序模拟向用户出售饮料的机器。该问题的规格说明如下:1听饮料价值1.5元,自动饮料机仅接受1元硬币和5毛的硬币,当硬币总额超过1.5元以后,机器拒绝接受更多的硬币。机器在用户硬币金额不足、没有饮料、没有找零的硬币时会分别显示“Inadequacy”, “NoDrink” 和 “NoChange”,在这些情况下,无法完成饮料购买的交易。在正常情况下,机器显示“Ready”。
本文利用CPN tools建成的自动饮料机的模型如图1所示。
在该模型中共包含三个CPN变迁:“Insert Coin”、“Push_DrkBtn”、“Push_BkBtn”分别表示用户塞入硬币、按下饮料按钮、按下退币按钮等三个不同的动作。模型包含的9个库所,分别表示系统不同的属性数值,各个库所的含义表1所示。通过定义CPN变迁关联的类型和函数声明,可以容易定义自动饮料机的不同特性。为了表示饮料机不同类型的变量,本文引入颜色集:INFOSET、NickelNum、DimeNum、DrkNum、CoinNum、Pushed。其中颜色集NickelNum、DimeNum、DrkNum都是整数类型,分别表示5毛硬币、1元硬币和饮料的数量。颜色集 INFOSET 是用于表示系统状态的枚举类型,包括“Inadequacy”, “NoDrink” 和 “NoChange”以及“Ready”四种状态。为了简化问题的描述和讨论的方便,我们引入笛卡尔乘积类型的颜色集CoinNum,表示1元硬币和5毛硬币的组合,(1,0)表示仅有一枚5毛硬币,其他依次类推。CPN模型中的每一个库所存储用户通过GUI组件输入或者系统内部维护的数据。每一个库所关联一个颜色集,如临时硬币缓冲区库所“Coin Cache”和内部硬币池库所“Coin_pool”分别关联着CoinNum类型,而信息窗口库所“Info Window”关联着INFOSET类型。
2 基于CPN状态空间的测试覆盖准则
2.1 CPN状态空间
CPN模型所有的库所标识构成了被测系统的一个状态,通过CPN变迁的触发引起系统由一个状态向另一个状态转变,从而实现系统行为的动态模拟。模型变迁的触发表示系统接收一定操作和外部输入,如用户通过界面输入一个数据,或者用户点击一个界面按钮,或外部接口系统输入一个触发的信号等。奥尔胡斯大学的CPN tools提供了系统模型的状态空间自动计算,并且支持状态生成的结束、分支等选项的设置,用户可以根据实际需要控制状态空间的产生,以防止出现状态爆炸。一个状态空间可以用一个三元组<S0,S,T>表示:
· S0∈S ,S0是状态空间的初始状态,初始状态由CPN模型的所有初始标识构成。
· S是状态空间所有状态的集合,∀Si∈S,Si可以从S0出发通过一系列的变迁触发,到达Si。
· T 是变迁的集合,当Ti 相关联的所有输入弧表达式能够计算成为和各自当前托肯(Token)兼容的多重集,并且该变迁的守护函数(Guard)也满足时,T中所有元素Ti处于使能状态。
在CPN tools 工具中,要计算出状态空间之前,必须先进入状态空间计算工具。对于较小的状态空间,可以直接采用计算状态空间工具进行计算。同时要求CPN模型具备下列三个条件:
· 模型不存在任何的语法错误;
· 所有的库所、变迁以及页面必须具有非空的命名;
· 所有的库所、变迁以及页面必须复合唯一的ML命名规则。
状态空间的每一个节点关联着三个整数,上部的整数是状态节点的编号,下面两个整数是当前节点的前驱状态节点和后继状态节点的数量。图2为自动饮料机在用户仅有一枚5毛硬币情况下CPN模型生成的状态空间图。状态节点1是该空间的初始状态,该状态节点有一个前驱状态节点,就是他本身,有两个后继状态节点,自身节点和状态节点2。
每一个节点均包含一个状态的内部详细信息,包括饮料机饮料数量、用户放入机器的硬币数量、机器拥有的零钱数量等,图1中节点4的状态内部信息如下列代码所示:
onenickel_model′ BkBtn 1: 1′ DOWN
onenickel_model′ DrkBtn 1: 1′ DOWN
onenickel_model′ Coin_Slot 1: 1′ (1,0)
onenickel_model′ Drk_Pool 1: 1′ 5
onenickel_model′ Drk_Slot 1: 1′ 0
onenickel_model′ Coin_Pool 1: 1′ (5,0)
onenickel_model′ Coin_Cache 1: 1′ (0,0)
onenickel_model′ Coin_Insert_Slot 1: empty
onenickel_model′ Info_Window 1: 1′ Ready
每条状态变迁信息和状态空间的变迁相联系,每一条信息描述了变迁的初始状态和终止状态,引起状态变化的CPN变迁名称以及变量的绑定情况。在用户没有塞入任何硬币之前,无论用户按下饮料按钮和退币按钮,均不会引起状态的任何变化,如图2中起始和终止均为节点1的两个变迁。在这种情况下,两个变迁信息描述如下:
2: 1->1 onenickel_model′ Push_DrkBtn 1: {n1=0, d1=0, drk1=0, info=Ready, n=0,d=0, d3=0, n3=5, drk=5, p=DOWN}
3: 1->1 onenickel_model′ Push_BkBtn 1: {info=Ready, n1=0, d1=0, n=0, d=0, p=DOWN}
在这两个变迁信息中,第1个数字表示的是变迁的编号,紧跟着编号的是变迁的起始节点和终止节点。其后是引起变迁的CPN变迁名字和相关的状态内部信息。状态变迁信息为访问状态空间的不同状态提供了方便,为基于状态空间的测试奠定了基础。
2.2 测试覆盖准则
状态空间中不同两个状态之间有无限多的路径,一般而言,测试无法覆盖所有可能的路径。受基于规格说明的测试用例[6]的启发,本文针对CPN状态空间提出了四种不同覆盖准则作为测试用例生成的依据。每一个覆盖准则需要不同数目的测试用例。对于状态空间<S0,S,T>,设si∈S并且ti∈T,对于所有的0≤i≤n,当s0=S0并且
· 状态覆盖State Coverage(SC):当测试集TS生成的路径P包含了每一个si∈S,测试集TS满足状态覆盖;
· 变迁覆盖Transition Coverage(TC):当测试集TS生成的路径P包含了每一个ti∈T,测试集TS满足变迁覆盖;
· 状态对覆盖State Pair Coverage (SPC):当测试机TS生成的路径包含了状态空间的每一个状态对(状态对由当前节点和其直接的前驱或者直接的后记节点构成),测试集TS满足变迁对覆盖;
· 变迁对覆盖Transition Pair Coverage(TPC):当测试机TS生成的路径包含了状态空间的每一个变迁对(状态对由当前节点的输入弧和输出弧对构成),测试集TS满足变迁对覆盖。如节点3所有状态对包括了(2,Push_BKBtn,4, Push_BKBtn 4)、(2,Push_BKBtn,4, Push_DrkBtn 4)、(3, Push_BKBtn ,4, Push_DrkBtn 4)、(3, Push_BKBtn ,4, Push_BKBtn 4)、(4, Push_DrkBtn 4, Push_DrkBtn 4)、(4, Push_DrkBtn 4, Push_BkBtn 4) (4, Push_BKBtn 4, Push_DrkBtn 4)、(4, Push_BKBtn 4, Push_BKBtn 4)。
3 应用实例
本节依据第1节的CPN模型和第2节讨论的测试覆盖准则来讨论基于CPN状态空间的测试方法,在不同的饮料机场景下比较不同的覆盖准则的差异。
场景1 用户仅有1枚价值5毛的硬币。
在该场景下,用户无法成功购买饮料,场景的重点在于测试不同操作次序产生的系统状态是否正确。由CPN 模型所产生的状态空间如图1 所示。表2由“Insert_Coin, Push_DrkBtn, Push_BkBtn”组成的操作序列覆盖了状态空间的所有状态,满足SC覆盖准则。
在每一条变迁信息中,紧跟着变迁序号的是变迁的起始状态和终止节点。在一些特殊的变迁中,起始节点和终止节点都是该节点的本身。例如在用户没有塞入硬币之前,用户按下饮料按钮DrkBtn和退币按钮BkBtn均不应引起系统状态的改变,第二节中讨论的第2条和第3条的变迁信息反映的就是这种情况,即状态节点1中的变迁Push_DrkBtn和Push_BkBtn不会引起状态的改变,其起始状态和终止状态都是状态节点1。在变迁覆盖中,无论变迁是否指向同一节点均应被测试用例所覆盖,通过变迁覆盖TC产生的测试集如表3所示。
状态对由当前状态节点的两个直接的相邻节点组成。如节点3有2个前驱状态节点和2个后继节点构成。针对节点3显然我们构造满足SPC准的测试集,如表4所示。
满足SPC准则的测试集数量TCN可以通过下面的公式进行计算。
TCN=∑
式中,PNi 和 SNi分别表示前驱状态节点和后继状态节点的数量,这两个值在状态空间中已经有CPN 工具直接给出,因此在该状态空间中,满足SPC准则的测试用例数量为11。同样的方法,计算出TPC准则的测试用例集中的测试数量,由下式表示:
TCN=∑
式中,PANi 和 SANi分别表示状态节点i的输入弧和输出弧的数量,依据场景1的状态空间,可以得到测试用例集的数量如表5所示。
场景2 用户用足够的钱购买饮料,并且机器有足够的零钱。
假设用户拥有2枚1元的硬币,这个场景中库所Coin_Insert_Slot的初始标记为(0,2),而库所Drk_Pool 和Coin_Pool 的初始标记为 1′5 和 1′(5,0)分别表示饮料和零钱足够。这个场景的状态空间如图3所示,当用户塞入2枚1元的硬币以后,机器的状态由状态1转换成状态2。状态3和状态4分别表示成功购买和用户按下退币按钮时的状态。在这个状态空间中,状态1、状态3和状态4分别有两个变迁的出发节点和终止节点为同一个节点。
场景3 用户需要找零,但饮料机中没有零钱。
Coin_Pool 的初始状态设置成为 1′(0,0) 来表示机器中没有零钱。由于没有零钱可以找零,在用户需要找零时是无法成功购买饮料的。为了减少用户金额变化而产生的状态数量,防止出现状态爆炸,我们将“Insert coin”变迁的弧设置成双向弧,在这种场景下的状态空间如图4所示。
场景4 机器中的饮料已经售完。
若机器中的饮料已经卖完,无论如何用户都无法成功购买饮料。场景4和场景2具有相同的状态空间,如图4所示。操作序列在两个场景中也相同,但是同一个节点在两个不同的场景中的含义不尽相同。自动饮料机4个不同的场景根据SC、TC、SPC和TPC生成不同数量的测试用例集,如表6所示。
根据状态空间覆盖测试的定义和表6给出实际测试数据,一般情况下TC涵盖了SC,SPC涵盖了TC,TPC涵盖了SPC,不同的状态空间的结构生成测试数量差别非常大。
4 结 论
着色Pertri 网具有动态生成和分析系统状态空间的优点。本文提出了使用CPN状态空间测试的覆盖准则,在对自动饮料机进行CPN建模并根据不同的场景生成和分析了对应的状态空间基础上,分析了依据不同覆盖准则生成测试用例。实践证明该方法是有效的。
摘要：CPN作为一种重要的建模工具,组合了高级编程语言和常规Petri网的优点,具有状态空间仿真和分析能力。提出了针对CPN状态空间的四种覆盖准则:状态覆盖、变迁覆盖、状态对覆盖、变迁覆盖,对自动饮料机系统进行了CPN建模,并用四种不同场景的CPN状态空间的覆盖准则来阐述该方法的有效性。
软件状态管理 篇5
关键词：MATLAB,图形用户界面,现代控制理论,仿真
0引言
MATLAB是矩阵实验室(Matrix Laboratory)的简称,是由美国MathWorks公司发布的一套主要面对科学计算、可视化以及交互式程序设计的高科技计算环境。其应用范围非常广,包括数值分析、工程与科学绘图、控制系统的设计与仿真、数字图像处理技术、数字信号处理技术和通讯设计与仿真等。本文主要应用了MATLAB的GUI图形用户界面来实现《现代控制理论》主要内容的仿真。
1现代控制理论与GUI
1.1 现代控制理论
现代控制理论是对古典控制理论的进一步发展,它包括线性系统理论、最优控制、现代系统辨识及自适应控制等多个分支。对现代控制理论做出重大贡献的有苏联科学家JI.C庞特里亚金提出的名为极大值原理的综合控制系统的新方法、美国贝尔曼(Bellman)的动态规划和匈牙利卡尔曼(Kalman)的滤波、能控性与能观性理论。这些研究成果解决了空间技术中出现的复杂控制问题,并开拓了控制理论中最优控制理论这一新的领域。这些就构成了后来被称为现代控制理论的发展起点和基础[1]。现代控制理论以线性代数和微分方程为主要的数学工具,以状态空间法为基础,分析与设计控制系统。
状态空间法对揭示和认识控制系统的许多重要特性具有关键作用。其中能控性和能观性尤为重要,成为控制理论的两个基本概念。现代控制理论在其诞生的近50年来,不论在理论还是应用方面一直处于十分活跃的状态,不仅在航空航天领域取得了惊人的成就,而且在自然科学和社会科学领域都得到了广泛的应用[2]。
1.2 用户界面
用户界面(或接口)是指用户与计算机信息交换的硬件、软件部分。图形用户界面(Graphical User Interfaces ,GUI)是指采用图形方式显示的计算机操作用户界面,是指由窗口、菜单、对话框等各种图形对象组成的用户界面。在这种用户界面下,用户必须对功能对象进行界面布局和编程,从而使用户在激活GUI 的功能对象时能够执行相应的行为。
MATLAB提供了一个可视化的图形界面开发环境GUIDE(Graphic User Interface Development Environment)。 GUIDE是一个界面设计工具,且所有GUI的控件都集成在这个环境中并提供界面属性、外观和行为响应方式的设置方法。GUIDE将程序员设计好的GUI界面保存在一个FIG文件中,同时还自动生成一个M文件。这个M文件为实现回调函数提供一个参考框架,这样既简化了GUI应用程序的创建工作,程序员又可以直接使用这个框架来编写自己的函数代码[3,4]。
GUIDE可在布局GUI的同时生成以下两个文件:①FIG文件,该文件包括GUI的图像窗口和所有子对象(包括用户控件和坐标轴)的完全描述以及所有对象的属性值;②M文件,该文件包括用户用来发布和控制界面和回调函数(这里作为子函数)的各种函数。该文件中不包含任何组件的布置信息[5]。
2用MATLAB的Control Toolbox完成软件设计
2.1 设计的步骤
设计步骤具体如下:①打开MATLAB,新建一个GUI;②在GUI界面中加入能完成实验的相应控件,如pushbutton(按钮)、static text(静态文本)、edit text(可编辑文本)、panel(面)、axes(坐标轴)等;③把相同类型的按钮放在同一个panel中,并布局好整个界面,使其看起来整洁美观;④修改各个控件的属性,以便在界面上观察其具体作用;⑤对各个按钮进行回调函数的编写,使其达到它的功能,这是设计GUI中最关键的一步;⑥对整个界面进行运行,就会得到相应的结果。
2.2 设计出的人机交互界面
设计出的人机交互界面见图1。
2.3 人机交互界面中控件的回调函数
(1)状态空间模型转换为传递函数模型的回调函数:
function pushbutton1_Callback(hObject, eventdata, handles)
h=handles.edit1;
ss=str2num(char(get(h,'String')));
A=ss
h=handles.edit2;
ss=str2num(char(get(h,'String')));
B=ss
h=handles.edit3;
ss=str2num(char(get(h,'String')));
C=ss
h=handles.edit4;
ss=str2num(char(get(h,'String')));
D=ss
[num,den]=ss2tf(A,B,C,D);
num=num2str(num);den=num2str(den);
set(handles.listbox1,'String',char('num=',num,'den=',den))
(2) 能控标准型的回调函数:
function pushbutton3_Callback(hObject, eventdata, handles)
h=handles.edit1;
ss=str2num(char(get(h,'String')));
A=ss
h=handles.edit2;
ss=str2num(char(get(h,'String')));
B=ss
h=handles.edit3;
ss=str2num(char(get(h,'String')));
C=ss
h=handles.edit4;
ss=str2num(char(get(h,'String')));
D=ss
[Ab,Bb,Cb,T,K]=ctrbf(A,B,C)
Ab=num2str(Ab);Bb=num2str(Bb);Cb=num2str(Cb);
set(handles.listbox1,'String',char('Ab=',Ab,'Bb=',Bb,'Cb=',Cb))
(3)回调函数的脉冲响应:
function pushbutton5_Callback(hObject, eventdata, handles)
h=handles.edit1;
A=str2num(char(get(h,'String')));
h=handles.edit2;
B=str2num(char(get(h,'String')));
h=handles.edit3;
C=str2num(char(get(h,'String')));
h=handles.edit4;
D=str2num(char(get(h,'String')));
sys=ss(A,B,C,D)
%axes(handles.axes1);
impulse(sys)
grid on
3结论
本文提出了用MATLAB的GUI设计图形用户界面,该方法将《现代控制理论》的知识点都体现在GUI中,实现了《现代控制理论》中主要的计算过程,且界面简洁,操作方便。
参考文献
[1]袁德成.现代控制理论[M].北京:清华大学出版社,2007.
[2]刘豹.现代控制理论[M].北京:机械工业出版社,1988.
[3]柴瑞娟.基于MATLAB GUI的线性控制系统教学仿真软件的设计[J].计算机与现代化,2003(9):68-70.
[4]李显宏.MATLAB7界面设计与编程技巧[M].北京:电子工业出版社,2006.
软件状态管理 篇6
作状态后, 由于其完成需要较长时间, 这时软件进入“忙状态”, 给用户的感觉是软件此时无响应, 键盘和鼠标等外部设备也停止了工作。对于这种情况, 一般的解决办法有两种:方法一:新建一个工作线程, 将该功能模块从主线程移到新建的工作线程中;方法二:通过特定界面, 为用户提供相应的状态提示, 使其明确此时软件正在干什么, 从而避免认为软件“死机”。
针对以上情况, 给出一个基于VC的动态链接库, 当软件进入“忙状态”时, 开发人员通过调用接口函数, 在屏幕中央位置出现一个长条状的显示面板, 告诉用户目前软件正在干什么, 当“忙状态”结束, 再通过接口函数关闭该面板, 从而避免了用户的误解。
(1) 设计思想
动态链接库InfoPanel采用VC实现。只提供一个stdcall调用的API接口SetInfoText, 原型为:void SetInfoText (const char*lpszText) ;参数lpszText为要在面板上显示的“忙”信息。调用流程如图1所示。
当应用程序需要启动面板时, 调用InfoPanel.dll的输出函数SetInfoText。这时dll将启动用户界面线程ThreadFunc, 线程为用户显示面板窗体, 并显示相应的“忙”信息。当应用程序“忙状态”结束, 只需再次调用SetInfoText, 并将其中的参数lpszText设置为空字符串, 这时dll将关闭面板窗体, 退出用户界面线程, 一次完整的调用结束。应用程序可继续后续功能。
(2) 具体实现
(3) 调用
这里给出在VB.Net中的调用示例。
声明如下:
以上代码在VS2003中调试通过。
(4) 结语
软件状态管理 篇7
密闭装备空间状态远程移动监控终端软件可用于粮库、档案馆、文物展陈、军火库等领域的监控。虽然目前已有一些基于无线传感网的远程移动监控终端软件, 但是仍有众多缺陷, 如数据实时性不高、数据不准确等, 且现有监控终端软件不能解决针对如矿井、军火库等人类难以进入的密闭空间的实时监控。
温度和湿度的远程测量和控制对于异地设备获得适宜的工作环境, 实现无人值守的正常运行具有重要意义。[1]通过对国内外已有监控系统的调研, 尽可能设计出最合理最优化的监控终端软件。在普通监控终端软件的基础上, 全面考虑人类难以接触、不便进入的密闭空间所要注意的监控内容, 如温湿度、气压、可燃气体、烟雾等。所要做的就是设计一个便于工作人员通过用移动终端, 如手机、平板电脑等 (安装有安卓系统) 即可对密闭空间状态进行远程监控的系统, 实现随时随地第一时间的监察控制。可用于如下领域:粮库温湿度监控;档案库、馆藏图书、文物展陈温湿度监控;煤矿安全监控;军火库、装备器材库安全监控。
对于粮库、档案馆、煤矿的使用的目的显而易见, 是为了保护农作物、以书籍的安全, 保障工人的生命安全, 但是对于军火库, 有更加重要的作用。军事重地向来需要具有极高的安全保密性, 且军队物资、装备属于极其贵重而易损物品, 这就需要诸如军火库、装备器材库等军事要地为密闭空间。近几年, 特别是大量新型武器装备后, 由温度、湿度、有毒气体、烟雾等环境问题给装备造成的损失逐年上升。所以, 实现切实可行, 实用性强, 实时性好, 数据传输效率高, 可靠性高的远程监测系统, 尤其是远程移动监控终端软件该测控系统就是迫在眉睫的一项任务。
2. 总体设计
2.1 功能描述
在考虑到本终端软件要求稳定可靠的数据传输时, 采用了TCP/IP协议作为本软件的网络传输层协议, 并使用socket技术实现数据的传输。利用基于TCP/IP的socket通信编程接口编写程序, 其目的是在TCP/IP所组建网络的不同机器之间利用客户/服务器模式建立通信连接[2]。由于TCP/IP协议的点对点的通信要求, 所以在整个系统之中, 要求服务器端时刻在线, 这也符合监控仪时刻检测密闭空间的需求。考虑到用户使用本软件的喜好和习惯, 设计两种监控方式:手动方式和自动方式。其中手动方式是通过在客户端选择不同的仓库编号、节点编号和各种项目 (温度、湿度等指标) 进行和服务器连接, 服务器接收到指令返回数据给客户的方式实现的;自动方式比较灵活, 它是是通过在客户端直接进行仓库编号和节点编号的选择进行和服务器连接, 从而返回数据的方式。其次, 由于密闭空间的温湿度等数据对于保密性和存储性具有比较高的要求, 所以, 分别要求有账户密码登录方式以及数据库存储方式实现以上功能。
2.2 实施方案
本终端软件包括对于温湿度、气压、可燃气体、烟雾进行监控。通过数字式传感器将密闭空间状态中待检测的信息, 如温湿度、气体 (甲烷、一氧化碳等) 浓度、气体压强、烟雾浓度等, 转化为数字信号, 通过无线通信方式将数据发送至安卓手机客户端并进行存储查验。通过客户端对服务器端进行请求实现点对点的数据传输方式 (TCP/IP) 。
2.3 实施计划
(1) 手持机选型;
(2) 手持机软件设计, 包括界面设计、数据库设计、收发机制设计等;
(3) 手持机数据导入软件设计。
在研制此软件的过程中, 考虑到包括远程节点的功耗限制, 设计手动和自动获取数据的方式。手动获取可以通过点击某个项目 (如:温度等) 进行连接获取数据;自动测试可以通过对于不同仓库的不同节点的选择进行自动获取本节点的数据获取。
2.4 系统结构
如图1所示, 用户通过手持移动终端 (安装有安卓操作系统) 通过无线局域网络将数据请求发送至汇聚节点, 汇聚节点再通过无线局域网络将此请求发送至密闭空间状态监控设备 (各种传感器) , 装备状态监控设备检测到相应的指令, 从其后台数据库或者进行实时监控将相应数据通过网络传送至汇聚节点, 汇聚节点再将数据返回至手持终端, 用户将得到此数据并将数据显示且存储。这就完成了一次命令请求和数据传送的过程。在整个过程中, 使用的是TCP/IP通信协议。
3. 开发环境和界面设计
3.1 开发环境搭建
本终端软件使用安卓操作系统和Java语言进行开发, 故, 使用Eclipse软件进行开发。此外, Android的应用程序开发和Java开发有较大区别的, 所以还需要有Google提供的Android?SDK。同时, 还需要在Eclipse安装ADT, 为Android开发提供开发工具的升级或者变更, 是Eclipse下开发工具的升级下载的工具。
3.2 主要用户界面效果图与设计说明
如图2所示, 当用户登录系统后, 选择了仓库编号和相应仓库的某个节点后, 即可点击“查询”按钮进行远程节点的连接, 同时已经将相应的查询命令发送至相应节点, 节点接收到指令, 就会把相应的实时数据返回给终端软件。另外, 软件会设计有语音提示功能, 数据返回会有语音提醒, 并且数据会自动存入数据库。用户可以点击“查看数据库按钮”进入数据库查看、删除相关数据项;点击“断开连接”按钮就会与相应的远程节点断开网络连接。如图3就是“自动查询数据库”界面设计。
此数据库起名为“自动查询数据库”是相对于后面的“手动查询数据数据库”来定义的, 从图3中可以看到数据很清晰地陈列出来, 每当数据是有危险 (意味着仓库内部某些指标不符合正常情况) 的时候, 数据库中的数据后会有三个“!”进行标注, 另外也会有语音提示。
手动查询的原理与自动查询是类似的, 也是通过先进行仓库和节点的选择, 然后实施查询的, 但不同的是, 手动查询更注重细致化, 细致到对某个节点某个指标的选择查询, 如图4所示, 当选择了仓库编号和节点编号之后, 还要点击选择这个节点的不同指标, 然后点击“查询”按钮才进行如自动查询那样的网络连接和指令发送。同时, 当数据有返回之时, 数据会自动显示在界面之上, 这也是和自动查询所不同之处, 因为这里的数据很简短, 只是某个数字或者某些字母, 不像自动查询返回的数据往往都是某个节点所有指标的信息, 直接展示会很不方便。同样的, 也可以通过点击“查看数据库”查询、删除相关数据项, 也会有相关的语音提示。每个软件必不可少的就是设置界面, 图5就是设置界面的简图。
从图5就可以看到, 设置界面中包含有几个“Text View”, 这里是把“Text View”进行了“button”化, 即, 将它们设计成具有不同功能的按钮, 点击之后会有不同的效果, 如网络测速、折线图显示间隔设置、锁屏时间设置、关于等。
将这三个界面合并在一起, 由于安卓中每个界面的设计是按照Activity进行的, 每个不同的界面就是一个Activity, 遂把这三个Activity放在一个大的Activity之中, 通过点击如图6的底部菜单栏的图标按钮进入不同的界面, 这也提升了软件的使用效果和用户体验水平。
4. 数据库 (SQLite) 设计
为了实现数据的实时存储、查询以及删除的功能, 必须要有数据库的支持, 而安卓中是使用SQlite进行数据的操作的。SQlite的通信协议是在编程语言内的直接API调用。这在消耗总量、延迟时间和整体简单性上有积极的作用。整个数据库 (定义、表、索引和数据本身) 都在宿主主机上存储在一个单一的文件中。它的简单的设计是通过在开始一个事务的时候锁定整个数据文件而完成的。[3]
当然, 安卓系统支持多种数据库形式, 但是SQlite是轻量型数据库, 它所占用的内存空间是很小的, 所以, 一般只用它对数据文件进行存储, 不用它来存储媒体文件, 这也符合本软件的设计需求。进入数据库时, 用户可以选择删除部分数据项或者清空数据库来释放内存空间。
本软件设计分别有两个数据库storeds.db和store.db, 分别代表自动查询数据库和手动查询数据库, 如表1和表2所示。
如表1和表2所示的数据库关键词列表可知, 两个数据库的内容是相似的, 这也是由于自动查询和手动查询的基本原理是相近的而导致的。但是, 明显的区别就是, 手动查询的数据库数据更加详细, 这也提升了软件的多用性。
5. 结束语
本文从设计案例开始着手分析近来监控系统中的终端软件的优缺点, 从而一步一步逐渐深入到需求与性能分析、总体软件的设计概想、总体和具体界面设计、数据库 (SQlite) 设计和具体的不同功能的文件设计, 层层深入, 解决不同的问题。在设计期间进行代码的撰写和案例的测试, 最终完成此项工程。
参考文献
[1]张星, 王向军, 文鹏程.基于TCP/IP协议的无线远程温湿度监控系统[D].天津:天津大学精密测试技术及仪器国家重点实验室, 2007.
[2]姜文平, 谭晖.基于TCP/IP的SOCKET接口实现网络通信[D].湖北:湖北省邮电科学研究院, 1998.
[3]SQLite文档[EB/OL].Categorical Index Of SQLite Documents, 2016/2/20.
软件状态管理 篇8
电压是电力系统的重要运行指标,也是电能质量的重要指标,而无功又是控制电压的决定性因素。随着社会经济的发展和人们生活对电能质量需求的不断增长,电压无功优化控制受到愈来愈多的重视[1,2,3,4,5,6,7,8,9]。电力系统规模的不断扩大、电网互联紧密度的不断加强以及电力系统复杂程度的不断提高,使得电压无功优化控制的规模越来越大,原来仅在变电站侧装设电压无功自动控制装置(VoltageQualityControl,VQC)进行无功补偿已不能满足需要,电网统一的自动电压控制系统(AutomaticVoltageControl,AVC)的研究和应用已经得到越来越多的研究人员和各级电网公司的重视[10,11,12]。自动化技术的发展使AVC得到了有效的应用,不仅提高了电压无功控制水平,也提高了控制效率(人工投切、调档)。AVC已成为目前电压无功控制追求的最高级形式。
浙江电网及其所辖地区电网也在积极开展AVC系统的研究与应用[13,14,15,16]。金华电网AVC单机系统于2004年正式投入运行,2006年完成了分布式二级控制改造[17],2009年实现了与浙江省调AVC系统的对接。目前,金华电网AVC系统已成为省地县三级协调控制的重要中间环节,在优化本级电网电压和无功的同时,执行省调AVC系统下达的调节指令,并向县调AVC系统下发合理的期望指标。
AVC省地县三级协调控制模式下,地区电网需要对三级AVC系统的协作情况进行有效的监控,确保各级AVC系统实现期望指标。在实现省地协调控制之前,地区电网可利用SCADA系统,根据省调下发的固定考核指标对关口功率因数进行监控。但是,在省地协调控制模式下,省调实时下发新的考核指标,而SCADA系统无法获取该指标信息,监控和调度人员也就无法实时判断关口功率因数的越限情况。同样,在地调AVC系统直接控制10kV电容器的模式下,监控人员只需要关注电容器投退情况即可,但是实现地县协调控制后,地调AVC系统不再直接下令投退10kV电容器,而是给县调AVC系统实时下达考核指标,这就需要实时监控县调AVC系统执行地调AVC系统指令的情况。尤其是在AVC系统出现异常时,对这些信息的监控显得更加重要。
本研究详细介绍了金华电网AVC省地县三级协调控制状态监控软件的设计开发方案。
1 AVC省地县三级协调控制模式
金华电网AVC系统同时与浙江省调AVC系统、金华电网所辖县(市)调AVC系统通信,是AVC省地县三级协调控制的中间环节。
省调AVC系统向地调AVC系统下达功率因数的考核指标;地调AVC系统向省调AVC系统上报可调能力及请求,并向县调AVC系统下达功率因数的考核指标。县调AVC系统执行地调AVC系统的考核指标并向地调AVC系统上报可调能力及请求。AVC省地县三级协调控制的框架结构如图1所示,具体的协调机制可以表述为:
(1)省调AVC系统:实时优化计算220kV变电站层面地调与省调的交换无功,向地调AVC系统下达变电站高压侧母线电压、关口无功或关口功率因数等目标指令。在正常情况下尽量维持各变电站无功就地平衡在电网电压越限且电厂失去调节能力的情况下,牺牲地调电网的无功平衡参与主网调压。
(2)地调AVC系统:将所辖各220kV变电站可投/切电容器容量上传至省调AVC系统,同时还向省调AVC系统提出所希望的关口电压。在满足省调AVC下发的220kV变电站关口无功和母线电压目标指令的前提下,实时优化本级电网电压和无功。若仅通过调整地调调度权限范围内的电容器和变压器分接头无法达到预期效果,则在综合考虑县调AVC系统提供的无功调节能力基础上,给县调下达各110kV变电站合理的期望指标。
(3)县调AVC系统:从县(市)电网角度出发,在满足地调AVC系统下达的考核指标前提下,实时优化本级电网电压和无功,并根据县(市)电网当前的运行情况,向地调AVC系统上报县调所辖范围内各110kV变电站的无功调节能力。当电压不合格而本身又无调节手段时,向地调AVC系统申请通过调节上级厂站的设备加以改善。
2 需求分析与功能设计
2.1 省地协调实时数据监视及历史数据查询
当省调AVC系统与地调AVC系统通信正常时,省调AVC系统每隔5min向地调AVC系统下达功率因数考核指标及调节指令,即实时考核指标;若地调AVC系统短时退出与省调AVC系统在线协调时,使用当天零点之前收到的随电压作阶段式浮动的功率因数考核指标,即日随电压考核指标;若过零点未收到日随电压考核指标,则使用离线定义的随电压作阶段式浮动的功率因数考核指标(即离线考核指标),如表1所示。
地调AVC系统在接受省调AVC系统控制命令的同时,也实时向省调AVC系统发送地调的可调节能力。因此,AVC省地县三级协调控制状态监控软件需实时获取并展示如下信息:
(1)省调AVC系统下发的关口功率因数实时考核上限下限调节指令包括上调下调和保持及下发时间;
(2)省调AVC系统下发的关口功率因数日随电压考核上限、下限;
(3)省调AVC系统下发的关口功率因数离线考核上限、下限;
(4)地调AVC系统实际采用的关口功率因数考核上限、下限(根据与省调AVC系统的通信情况确定);
(5)地调AVC系统上报的关口功率因数上限、下限及上报时间;
(6)关口实时功率因数;
(7)关口实时电压;
(8)关口功率因数越限情况(根据实际采用的考核指标判断)。
为在AVC系统调节失败后分析具体原因,AVC省地县三级协调控制状态监控软件需具备以上信息的历史记录查询功能。
2.2 地县协调实时数据监视及历史数据查询
与AVC省地协调控制不同,地县协调控制过程中没有日随电压考核指标和离线考核指标,地调AVC系统向县调AVC系统实时下达合理的期望指标。县调AVC系统实时向地调AVC系统上传县调的无功调节能力。因此,AVC省地县三级协调控制状态监控软件需实时获取并展示如下信息:
(1)地调AVC系统实时下发的关口功率因数考核上限、下限及下发时间;
(2)县调AVC系统实时上报的关口功率因数上限、下限及上报时间;
(3)关口实时功率因数;
(4)关口实时电压;
(5)关口功率因数越限情况。
为在AVC系统调节失败后分析具体原因,AVC省地县三级协调控制状态监控软件需具备以上信息的历史记录查询功能。
2.3 数据展示方式
AVC省地县三级协调控制状态监控软件提供两种方式的数据展示功能:报表展示及曲线展示。
报表展示方式将所有变电站同一个时间断面上的数据展示在一个报表界面内,并按照可设定的周期刷新,如图2所示。该种方式的优点在于展示数据精确,能够清楚地判断数据的微小变化,并方便不同变电站数据的对比,其缺点在于只能展示某一个时间断面上的数据,无法展示数据的变化趋势。
曲线展示方式将某一个变电站各指标信息24h内的数据动态展示在曲线上,如图3所示。其优点在于能够直观地展示数据的变化趋势,但与报表展示方式相比,该方式在一个界面上只能展示某一个变电站的数据,且精度上低于报表展示方式。
AVC省地县三级协调控制状态监控软件同时提供这两种数据展示方式,AVC专责管理人员可结合二者的特点,对AVC系统运行情况进行判断和分析。
2.4 越限告警
当省地县通信中断或者AVC系统内部出现异常时,AVC省地县三级协调控制可能会失败,从而引起关口功率因数越限。AVC省地县三级协调控制状态监控软件应当具备告警功能(包括语音告警及提示框告警),在连续出现几个(可设定)越限点后提醒AVC专职管理人员尽快查明原因并恢复AVC系统的正常控制。
2.5 考核统计
在AVC省地县三级控制模式下,省调定期考核地调AVC系统执行省调AVC系统指令的合格率,并将结果下发给地调。AVC省地县三级协调控制状态监控软件也对该考核结果进行统计,一方面可以与省调考核结果进行对比,另一方面可以在一个考核周期结束之前实时关注考核情况。
同时,地调也对县调AVC系统执行地调AVC系统指令的合格率进行考核。AVC省地县三级协调控制状态监控软件对该考核结果进行统计,作为对县调AVC运行管理工作考核的依据。
3 软件开发与应用
AVC省地县三级协调控制状态监控软件基于Qt构架开发。Qt构架具有很好的跨平台特性,因此,该软件既可以在UNIX系统上编译运行,也可以在Windows系统上编译运行。
本软件需要获取省调AVC、地调AVC、县调AVC3个系统的数据,其数据获取流程设计如图4所示。省调AVC系统在本地创建对应于各地调的指令文件后,通过省地通信通道发送到地调AVC服务器。县调AVC系统在本地创建请求文件后,通过地县通信通道上传到地调AVC服务器。地调AVC系统在本地创建包含实时关口功率因数和实时关口电压的文件。AVC省地县三级协调控制状态监控软件远程读取地调AVC服务器上的相关数据文件,经过计算、比较,将结果以报表和曲线的形式展示给用户,并将各个时间断面的数据进行存储以备历史查询。该软件可根据用户输入的查询条件,将历史数据提取出来并以报表和曲线的形式展示。在AVC系统调节失败后,该软件将发出语音报警。
AVC省地县三级协调控制状态监控软件已在金华电网投入试运行。目前,该软件运行稳定,为AVC专责管理人员提供了很好的参考。
4 结束语
软件状态管理 篇9
嵌入式系统开始于20世纪80年代单片机的使用。它给工业生产的监控带来极大方便。但是应用于工业生产的机械设备越来越趋向于复杂化、高速化、自动化、精准化及智能化, 这就要求功能强大的监控系统并且具有图形化的监测界面, 现今工业现场常采用PC工控机组成的监控系统, 缺点主要为体积过大、成本高、对环境的要求过高。但是传统的单片机是不能够满足要求的。半导体行业的快速发展, 使得32位的ARM处理器的性能不断增强, 价格也大幅度下降, 同时配合Windows CE.NET嵌入式操作系统, 能够达到很好的整体性能, 不仅在手持设备, 通讯设备和多媒体设备上有着广泛应, 而且其强大的运算功能, 丰富的通讯接口可满足工业控制要求。
1 Windows CE.net及开发工具Platform Builder5.0
Microsoft Windows CE.NET是Windows CE 3.0的后续产品, 为各种嵌入式系统和产品设计的一种压缩的、具有高效的、可升级的操作系统 (OS) 。其多线性、多任务、全优先的操作系统环境是专门针对资源有限而设计的。它具有可靠性好、实时性高、内核体积小及可伸缩性、强大的通信能力等特点, 可以按照用户的要求进行裁剪的32位实时嵌入式操作系统, 模块化设计使嵌入式系统开发者和应用开发者能够定做各种产品。Windows CE.NET支持各种硬件外围设备和网络系统。包括键盘、鼠标设备、串行端口、以太网连接器、调制解调器、通用串行总线 (USB) 设备、音频设备、并行端口、打印设备及存储设备, 例如PC卡等。
Windows CE.NET支持超过1 000个公共Microsoft Win32 API和几种附加的编程接口, 用户可利用它们来开发应用程序。这些接口包括:1) 组件对象模型 (COM) ;2) Microsoft基础类 (MFC) ;3) Microsoft ActiveX控件;4) Microsoft活动模板库 (ATL) 。
Windows CE.NET支持多种处理器产品, 包括x86, StrongARM, ARM, Xscale, MIPS和SH等系列。
Windows CE.NET系统主要由OEM层, Windows CE.NET组件及应用程序3个部分组成 (图1) , 其中OEM适配层 (OAL, OEM Adaptive Layer) 、设备驱动程序结合相应的配置文件便构成了Windows CE.NET的BSP (Board Support Package) 。
作为硬件抽象层的一种实现, 板级支持包BSP (board support package) 是现有的大多数商用嵌入式操作系统实现可移植性所采用的一种方案。BSP隔离了所支持的嵌入式操作系统与底层硬件平台之间的相关性, 使嵌入式操作系统能够通用于BSP所支持的硬件平台, 从而实现嵌入式操作系统的可移植性和跨平台性, 以及嵌入式操作系统的通用性、复用性, 能够支持更多硬件平台。
Platform Builder5.0是微软公司提供给Windows CE开发人员进行基于Windows CE平台下嵌入式操作系统定制的集成开发环境。它提供了所有进行设计、创建、编译、测试和调试Windows CE操作系统平台的工具。它运行在桌面Windows下, 开发人员可以通过交互式的环境来设计和定制内核、选择系统特性, 然后进行编译和调试。同时, 开发人员还可以利用Platform builder来进行驱动程序开发和应用程序项目的开发等等。Platform builder的强大功能, 已使其成为Windows CE平台下嵌入式操作系统开发和定制的必备工具。
2Window CE.net系统开发流程
硬件平台采用友善公司的QQ2440V3开发板, 硬件电路不需要进行自己设计, 系统开发 (图2) 主要包括两个部分:平台的定制和应用程序开发, 应用程序的开发将后一节专门介绍。
a) 平台定制:Window CE.NET最大的特点就是模块化, 用户可以根据自己的需求定制相应的操作系统, 定制的过程与外围设备是相关的, 在Platform builder 5.0的Catalog item下面是所有Windows CE支持的特征。由于要使用eMbedded Visual C++进行基于对话框的应用程序的开发, 要添加C语言和MFC支持。当所有的需要的组件添加完成之后, 进行编译, 生成系统映像系统映像文件NK.bin (或者NK.nb0) , 通过Samsung公司提供的下载工具DNW, 可以通过USB传输线将系统映像下载到硬件设备上运行。在极限情况下, Windows CE .net的最基本部分可以仅仅占用200K的空间。
b) 模拟器定制:在嵌入式设备上进行应用程序的开发和PC机上进行传统的应用程序开发相似, Windows CE.net平台下应用软件开发工具主要有eMbedded Visual C++或者Visual studio 2005, 通过借助于模拟器进行调试, 可以在缺少硬件的情况下进行应用程序开发。
eMbedded Visual C++中提供标准的模拟器, 该模拟器 (STANDARDSDK) 存在以下缺点:1) 标准模拟器不支持中文;2) 标准模拟器的显示分辨率的大小固定, 为800×600;3) 标准模拟器的显示亮度和灰度和实际屏幕之间存在差异。因此为了更加贴近项目中的实际情况, 有必要进行自定义模拟器的开发, 为更好支持监测软件的开发, 定制的模拟器分辨率为640×480, 并支持中文操作系统。
3 监控软件开发
下面为Windows CE.NET嵌入式操作系统监控软件开发, 图3为监控软件的结构, 该软件主要用于从以太网读取采集原始数据, 然后对振动数据进行处理, 最后将数据给图形显示模块进行实时显示, 3个模块可以对数据存储区进行读写, 通过人机交互模块可以实现对所有模块的状态控制。
a) 数据传输模块设计:数据传输模块主要由CTCPClientCE类来与TCP服务器建立连接, 进行数据传输。
CTCPClientCE类的主要流程为, 首先设置服务器IP地址, 端口号及处理回调函数, 再创建套接字, 创建成功后启动通讯线程, 定时查询端口时间, 一旦有数据则触发读事件发生, 读取成功后将数据保存, 再对端口进行查询, 其中一旦发成错误, 触发出错处理函数, 断开连接并结束程序。
b) 数据处理模块设计:图4为监控软件的数据流程, 从网络中的到的数据首先进行FFT处理, 然后再进行特征值提取, 最后惊醒趋势数据的提取。由于嵌入式处理器一般不支持浮点数, 为了保证数据精度要求, 所得到的数据都是经过放大的整型数据, 将数据放入数据存储区中, 再由数据处理线程从数据存储区中取得数据, 对数据进行处理, 数据处理模块中需要使用的浮点运算有很多, 例如正余弦、反正切、反余切、开平方等等, 在该监测软件中通过建立1024点的放大100倍的正余弦表, 来解决求解正余弦, 利用二分法来求解平方根, 能够迅速求解, 这样来避免进行浮点运算。
c) 数据显示模块设计:绘图过程大多放在OnDraw或者OnPaint函数中, OnDraw在进行屏幕显示时是由OnPaint进行调用的。当窗口由于任何原因需要重绘时, 总是先用背景色将显示区清除, 然后才调用OnPaint () , 而背景色往往与绘图内容反差很大, 这样在短时间内背景色与显示图形的交替出现, 使得显示窗口看起来在闪烁, 为了避免屏闪, 采用双缓冲绘图机制, 将首先将图形绘制于内存中, 然后将内存中的图拷贝到屏幕上进行显示。步骤如下:
首先调用Windows API32函数。
CreateCompatibleDC (NULL) , 创建一个屏幕兼容的内存DC, 然后调用函数:m_Bmp.
CreateCompatibleBitmap (&m_dcMemory, ScreenRect.Width () , ScreenRect.Height () ) 创建位图, 接着调用API32函数:SelectObject.
(m_dcMemory.GetSafeHdc () , m_Bmp) , 选择位图, 接着在位图中绘制图形, 完成后调用pdcView->BitBlt (0, 0, ScreenRect.Width () , ScreenRect.Height () , &m_dcMemory, 0, 0, SRCCOPY) 将内存中的图拷贝到屏幕上进行显示。
当应用程序开发完成后, 利用开发工具Platform Builder5.0, 打包进Windows CE.NET系统映像NK.bin。具体操作如下:
1) 找到Windows CE.NET目标工程目录, 例如:D:WINCE500PUBLICYC2440, 并且其中的工程已经编译成功。
2) 将应用程序Monitoring Software.exe复制到YC2440工程目录下, 目录为:
D:WINCE500PBWorkspacesYC2440RelDirsmdk2440_ARMV4I_Release。
3) 修改YC2440工程的project.bib文件, 在FILES Section添加如下内容:Monitoring Software.exe $ (_FLATRELEASEDIR) Monitoring Software NK H。
4) 创建快捷方式文件Monitoring Software.lnk, 新建一个txt文本, 然后打开文本, 添加如下内容:31#Windows
Monitoring Software.exe, 数值代表#后面字符数目, 然后将文件名改为:Monitoring Software.lnk, 将该快捷方式文件也添加到YC2440工程目录D:WINCE500
PBWorkspacesYC2440RelDirsmdk2440_ARMV4I_Release下。
5) 修改YC2440工程的project.bib文件, 在FILES Section添加如下内容:Monitoring
Software.lnk $ (_FLATRELEASEDIR) Monitoring Software.lnk NK H。
6) 修改YC2440工程的project.dat文件, 添加如下内容:Directory ("WindowsStartup") :-File ("Monitoring Software.lnk"
, "Windows Monitoring Software.lnk") 。
7) 修改YC2440工程的platform.bib文件, 在FILES Section添加如下内容:
Monitoring Software.exe $ (_FLATRELEASEDIR)
Monitoring Software.exe NK H
Monitoring Software.lnk $ (_FLATRELEASEDIR) Monitoring Software.lnk NK H
8) Platform Builder IDE:【Build OS】->【Make Run-Time Image】, 不需要重新编译, 这样, 将改动的部分添加进映像文件。
9) 成功后, 得到的映像文件NK.bin (或NK.nb0) 就包含了应用程序Monitoring Software.exe和Monitoring Software.lnk, 当把相应的内核烧入开发板后, 程序就会在系统启动时自动运行。图5为应用软件监控对通道1振动进行监测。
4 结语
主要介绍了在windows CE平台下嵌入式监控软件的开发, 该系统能够实现实时数据传输、处理与显示, 能够显示多种波形, 该系统体积小, 功能强大, 具有实际工程运用价值, 此外良好的C/C++开发经验对于该系统的开发具有促进作用, 并可能最终决定了系统的稳定性能。
参考文献
[1]Sikun Li, Zhihui Xiong, Tiejun Li.Distributed cooperative designmethod and environment for embedded system[J].IEEE Trans-actions on Consumer Electronics, 2005, 2 (24-26) :956-960.
[2]汪兵, 李存斌, 陈鹏.EVC高级编程及其应用开发[M].北京:中国水利水电出版社, 2005.
[3]陈连坤.嵌入式系统的设计与开发[M].北京:清华大学出版社, 2005.
[4]周毓林, 宁杨, 陆贵强, 等.Windows CE.net内核定制及应用开发[M].北京:电子工业出版社, 2005.
[5]何桂华.基于SamArmdvk9开发板的WINCE系统定制与安装[J].长沙电力学报:自然科学版, 2005, 30 (3) :54-56.
[6]何宗键.Windows CE嵌入式系统[M].北京:北京航空航天大学出版社, 2006.
[7]姜波.Windows CE.Net程序设计[M].北京:机械工业出版社, 2006.
【软件状态管理】相关文章：
航天项目技术状态管理12-16
状态标识管理规范04-22
状态标志管理制度04-23
状态标识管理制度04-24
技术状态管理培训讲义04-30
状态监测设备管理论文04-19
状态标志牌管理制度09-14
物的不安全状态的管理03-10
煤矿设备状态监测与维修管理研究10-18