3.1.1 系统工程
系统是由互相关联、互相制约、互相作用的若干组成部分构成的具有某种功能的有机整体,人们对于系统的认识,即关于系统的思想来源于社会实践。人们在长期的社会实践中逐渐形成了把事物的各个组成部分联系起来从整体角度进行分析和综合的思想,即系统思想。
系统思想古已有之,但系统工程的诞生却是近70年的事。随着科学技术的迅速发展和生产规模的不断扩大,迫切地需要发展一种能有效地组织和管理复杂系统的规划、研究、设计、制造、试验和使用的技术,即系统工程。
3.1.1.1 系统工程基本概念
系统工程是以大型复杂系统为研究对象,按一定目的进行设计、开发、管理与控制,以期达到总体效果最优的理论与方法。系统工程是一门工程技术,但又是一类包括了多类工程技术的一大工程技术门类,涉及范围很广,不仅要用到数学、物理、化学、生物等自然科学,还要用到社会学、心理学、经济学、医学等与人的思想、行为、能力等有关的学科。系统工程所需要的基础理论包括运筹学、控制论、信息论、管理科学等。
系统工程还是一个用于实现产品的跨学科方法,通过它可以将产品作为一个整体来理解,更好地构建产品规划、开发、制造和维护过程,对一个产品的需求、子系统、约束和部件之间的交互作用进行建模、分析,并进行优化和权衡,做出重要决策。在整个生命周期,系统工程师利用各种模型和工具来捕捉、组织、优先分级、交付并管理系统信息。
系统工程第一次提出并得到应用是在1940年。美国贝尔实验室研制电话通信网络时,将研制工作分为规划、研究、开发、应用和通用工程等五个阶段,并提出了排队论原理。1942年美国研制原子弹的曼哈顿计划也应用了系统工程原理进行协调。自觉应用系统工程方法而取得重大成果的两个例子是美国的登月火箭阿波罗计划和北欧跨国电网协调方案。
系统工程属于工程技术类,国内外有一些学者对系统工程的含义有过不少阐述,但至今仍无统一的定义。1967年,美国著名学者切斯纳(H.Chestnut)认为:“虽然每个系统都是由许多不同的特殊功能部分所组成,而这些功能部分之间又存在着相互关系,但是每一个系统都是完整的整体,每一个系统都有一定数量的目标。系统工程则是按照各个目标进行权衡,全面求得最优解的方法,并使各组成部分能够最大限度地相互协调。”1974年,大英百科全书将其定义为:“系统工程是一门把已有学科分支中的知识有效地组合起来用以解决综合化的工程技术。”1975年,美国科学技术辞典的论述为:“系统工程是研究复杂系统设计的科学,该系统由许多密切联系的元素所组成。设计该复杂系统时,应有明确的预定功能及目标,并协调各个元素之间及元素和整体之间的有机联系,以使系统能从总体上达到最优目标。在设计系统时,要同时考虑到参与系统活动的人的因素及其作用。”1977年,日本学者三浦武雄指出:“系统工程与其他工程学的不同之处在于它是跨越许多学科的科学,而且是填补这些学科边界空白的一种边缘学科。因为系统工程的目的是研制一个系统,而该系统不仅涉及工程学的领域,还涉及社会、经济和政治等领域,所以为了适当地解决这些领域的问题,除了需要某些纵向技术以外,还要有一种技术从横的方向把它们组织起来,这种横向技术就是系统工程。”1978年,我国著名学者钱学森指出:“系统工程是组织管理系统的规划、研究、设计、制造、试验和使用的科学方法,是一种对所有系统都具有普遍意义的方法。”从以上各种观点可以看出,系统工程是以大型复杂系统为研究对象,按一定目的进行设计、开发、管理与控制,以期达到总体效果最优的理论与方法。
综上所述,系统工程是运用系统思想直接改造客观世界的一大类工程技术的总称,是关于生产、建设、交通、储运、通信、商业、科学研究以及人类其他活动的规划、组织、协调和控制的科学方法。系统工程以系统为对象,从系统的整体概念出发,研究各个组成部分,分析各种因素之间的关系,运用数学方法,寻找系统的最佳解决方案,使系统总体效果达到最佳。
3.1.1.2 系统工程的特点
系统工程是一门工程技术,用以改造客观世界并取得实际成果,这与一般工程技术问题有共同之处。同时,系统工程又是包括了许多类工程技术的一大工程技术门类,与一般工程技术相比,系统工程有以下几大特点:
(1)研究对象广泛,包括人类社会、生态环境、自然现象和组织管理等。
(2)作为一门跨学科的综合学科,系统工程不仅要用到数学、物理、化学、生物等自然科学,还要用到社会学、心理学、经济学、医学等与人的思想、行为、能力等有关的学科,是自然科学和社会科学的交叉,因此,系统工程形成了一套处理复杂问题的理论、方法和手段,使人们在处理问题时,有系统的、整体的观点。
(3)在处理复杂的大系统时,常采用定性分析和定量计算相结合的方法。因为系统工程所研究的对象往往涉及人,这就涉及人的价值观、行为学、心理学、主观判断和理性推理,因而系统工程所研究的大系统比一般工程系统复杂得多,处理系统工程问题不仅要有科学性,而且要有艺术性和哲理性。
(4)系统工程研究问题一般采用先确定整体框架,后进入详细设计的程序,一般是先进行系统的逻辑思维过程总体设计,然后进行各子系统或具体问题的研究。
(5)系统工程方法是以系统整体功能最佳为目标,通过对系统的综合、系统分析构造系统模型来调整改善系统的结构,使之达到整体最优化。
(6)系统工程研究是以系统思想为指导,采取的理论和方法是综合集成各学科、各领域的理论和方法,强调多学科协作,根据研究问题涉及的学科和专业范围,组成一个知识结构合理的专家体系。
3.1.1.3 系统工程方法论
1957年,美国的H.H.古德(Harry H.Goode)和R.E.麦克霍尔(Robert E.Machol)合作发表了第一本完整的系统工程教科书——《系统工程》(System Engineering)。随后,麦克霍尔又于1965年发表了《系统工程手册》(System Engineering Handbook)一书。这两本书以丰富的军事素材论述了系统工程的原理和方法。1962年,A.D.霍尔发表的《系统工程方法论》(A Methodology for System Engineering)一书反映了作者长期从事通信系统工程的成果,内容涉及系统环境、系统要素、系统理论、系统技术、系统数学等方面。A.D.霍尔还于1969年提出著名的霍尔三维结构,即系统工程形态图。到60年代末,关于军事和工程等系统的系统工程方法论已臻于完善。
霍尔三维结构又称霍尔系统工程,后人将其与软系统方法论对比,称其为硬系统方法论(Hard System Methodology,HSM)。它的出现,为解决大型复杂系统的规划、组织、管理问题提供了一种统一的思想方法,因而在世界各国得到了广泛应用。霍尔三维结构是将系统工程整个活动过程分为前后紧密衔接的七个阶段和七个步骤,同时还考虑了为完成这些阶段和步骤所需要的各种专业知识和技能,这样,就形成了由时间维、逻辑维和知识维所组成的三维空间结构:①时间维表示系统工程活动从开始到结束按时间顺序排列的全过程,分为规划、拟定方案、系统研究、生产、安装、运转、更新七个时间阶段。②逻辑维是指时间维的每一个阶段内所要进行的工作内容和应该遵循的思维程序,包括明确问题、设计系统指标、系统综合、系统分析、系统优化、决策、实施七个逻辑步骤。③知识维列举需要运用的包括工程、医学、建筑、商业、法律、管理、社会科学、艺术等各种知识和技能。三维结构体系形象地描述了系统工程研究的框架,对其中任一阶段和每一个步骤,又可进一步展开,形成了分层次的树状体系,如图3.1所示。
图3.1 霍尔三维结构模型
3.1.2 体系架构
3.1.2.1 体系架构基本概念
系统体系架构是指系统的组成结构及其相互关系,是指导系统设计和发展的原则。系统体系架构是一个综合模型,由许多结构要素及各种视图(或观点)(View)所组成,而各种视图主要是基于各组成要素之间的联系与互操作而形成的,如图3.2所示。所以,系统体系架构是一个综合各种观点的模型,用来完整描述整个系统。
图3.2 系统体系架构
体系架构框架则是一种用于系统体系架构开发、描述和集成的统一方法,提供了开发和表述体系架构的规则、指南和产品描述,提供了理解和管理复杂的体系架构设计的一种机制。
本质上,系统体系架构是一个系统建模的方法,在系统体系架构的各种视图中,以组织视图与行为视图最为突出和重要。所以,要完成各种视图的综合,必须先完成组织与行为视图的统一。通过组织视图与行为视图的综合过程,就可以构建出一个可以完整描述的系统。所以,系统体系架构框架可以作为构建系统模型的一种方法。
体系架构是对复杂事物的一种抽象。良好的体系架构是普遍适用的,它可以高效地处理多种多样的个体需求。提起“房子”,人们的脑中马上就会出现房子的印象(而不是地洞的印象)。“房子”是人们对住宿或办公环境的一种抽象。不论是办公楼还是民房,同一类建筑物(甚至不同类的建筑物)之间都具有非常相似的体系结构和构造方式。
一般来说,系统或软件体系架构都需要用相应的体系架构描述语言(Architecture Description Language)来描述,其目的在于为体系架构进行描述和呈现,为体系架构中的相关人员(如管理人员、系统开发人员和用户等)提供可以进行沟通的语言。目前已有多种体系架构描述语言,如卡内基梅隆大学的ACME和Wright,斯坦福大学的Rapide,IBM公司的UML等。
体系架构设计技术是信息时代解决巨型复杂系统顶层设计的重要手段,因此体系架构及其框架技术已成为系统工程的必备要素,可结合实际情况运用到各类系统工程实践中。
在军事、安防等领域,体系架构设计技术得到了尤为广泛的运用,这主要得益于美军在实施系统工程方面的引领和实践。体系架构是美军进行武器装备体系顶层设计的重要手段,并日益展现出显著的优点和巨大的潜力,有力地支持了军队转型和信息化武器装备体系的建设。为了构建适应21世纪战争需要的武器装备体系,一些发达国家和地区的军队也纷纷仿效美军的做法,开展体系架构技术研究,推动了体系架构技术理论研究和应用实践的不断深入,体系架构工具、数据模型、知识库等得到了不断发展和完善。
3.1.2.2 信息系统体系架构
信息系统体系架构是近年来出现的新的研究领域,尚无公认的定义。作为一个典型的体系架构,它反映一个政府、企业或事业单位的信息系统的各个组成部分之间的关系,以及信息系统与相关业务、信息系统与相关技术之间的关系。
在信息系统体系架构设计中,分层式结构最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层(图3.3),从下至上分别为:数据访问层、业务逻辑层(或称为领域层)和表示层。三层体系结构,是在客户端与数据库之间加入了一个“中间层”,也叫组件层。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即把这三个层放置到一台机器上。
图3.3 典型的微软三层体系图
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互。
(1)数据访问层:主要看数据层里面有没有包含逻辑处理。实际上,数据访问层主要完成对数据文件的各个操作,而不必管其他操作。数据访问层有时候也称为持久层,其功能主要是负责数据库的访问,可以访问数据库系统、二进制文件、文本文档或是XML文档。简单地说,就是实现对数据表的Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的Mapping,以及对象实体的持久化。数据访问层主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务。
(2)业务逻辑层:主要是针对具体问题的操作,也可以理解成对数据的业务逻辑处理。如果说数据层是积木,那逻辑层就是对这些积木的搭建,主要负责对数据层的操作,也就是说把一些数据层的操作进行组合。业务逻辑层无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,即它是与系统所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。例如Martin Fowler在Patterns of Enterprise Application Architecture[1]一书中,将整个架构分为三个主要的层:表示层、领域层和数据源层。业务逻辑层在体系架构中的位置很关键,它处于数据访问层与表示层中间,起到了数据交换中承上启下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有任何影响。正因为如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都体现在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任务。
(3)表示层:表示层位于最外层(最上层),离用户最近,用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面,既可表示为WEB方式,也可以表示成WinForm方式。如果业务逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。
3.1.2.3 Zachman框架
John Zachman是一个在体系架构概念化和企业体系架构规划领域享有盛誉的领导者。1987年8月,John Zachman在《IBM系统月刊》上发表了一篇文章,名为A Framework for Information Systems Architecture(《信息系统体系架构框架》)[2],这种体系结构被称作Zachman体系架构。
Zachman体系架构为理解复杂系统架构提供了一个易于理解的逻辑方法。体系架构使得涉及开发或设计等不同任务的参与者之间能够有效交流,使得系统能够融为一体。体系架构框架定义了一系列的体系架构,包含架构开发模块。作为管理企业中变革变化和系统集成的体系架构,它已经得到全世界的认同。
在Zachman体系架构中有两个重要思想:①在建立复杂的工程产品过程中产生许多体系架构描述,不同的产品表现系统不同部分的各个方面;②同一产品可以出于不同的目的、不同的方式进行描述。
图3.4 Zachman视图
Zachman体系架构提供详细的企业信息系统内容和企业信息系统架构的视图,如图3.4所示,它概括地描述6个不断增加详细程度的视图和对6个体系架构描述的抽取的级别。这6个视图分别是:①计划者(Planner)或活动领域视图;②所有者(Owner)或企业模型视图;③设计者(Designer)或系统模型视图;④建设者(Builder)或技术模型视图;⑤分包者(Subcontractor)或详细描述视图;⑥用户(User)或运行中的企业视图。
而从另一个角度来看,Zachman体系架构讲述了6个方面的描述内容:①Data Description(数据描述);②Function Description(功能描述);③Network Description(网络描述);④People Description(人物描述);⑤Time Description(时间描述);⑥Motivation Description(动机描述)。(www.xing528.com)
3.1.2.4 面向服务的体系架构(SOA)
面向服务的体系架构(Service-Oriented Architecture,简称SOA)是一种松耦合的应用程序体系架构(图3.5),起源于20世纪80年代中期,并逐渐成为一个被大家广泛认可的规范。由于提供了一个抽象的服务层,对服务使用者隐藏了服务的实现细节,使得SOA在需求和应用环境需不断改变的应用程序开发中得到了很好的应用。互联网的发展,特别是WebService的出现,为部门内部及部门之间提供了廉价而简便的通讯支持。同时,基于SOA的体系架构与以应用为中心的一体化应用程序相比,具有高度开放性、灵活性和可重用性等特点。
图3.5 典型SOA架构
面向服务的体系架构是一个组件模型,它将应用程序的不同功能单元(称为服务),通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它独立于实现服务的硬件平台、操作系统和编程语言,这使得构建在这样的系统中的各种服务可以用一种统一和通用的方式进行交互。
这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点:首先是它的灵活性;其次是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。
对松耦合系统的需要来源于业务应用程序的需要,根据业务的需要变得更加灵活,以适应不断变化的环境,比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的性质。通常将能够灵活地适应环境变化的业务称为按需业务,在按需业务中,一旦需要,就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系架构不是一个新鲜事物,但它却是更传统的面向对象模型的替代模型,面向对象的模型是紧耦合的,已经存在二十多年了。虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务,但是其整体设计却是面向服务的。由于它考虑到了系统内的对象,所以虽然SOA是基于对象的,但是作为一个整体,它却不是面向对象的,不同之处在于接口本身。
实际上,SOA作为一种面向服务的架构,是一种软件架构设计的模型和方法论。从业务角度来看,一切以最大化“服务”的价值为出发点,SOA利用企业现有的各种软件体系,重新整合并构建起一套新的软件架构。这套软件架构能够随着业务的变化,随时灵活地结合现有服务,组成新软件,共同服务于整个企业的业务体系。简单地理解,可以把SOA看作是模块化的组件,每个模块都可以实现独立的功能,而不同模块之间的结合则可以提供不同的服务,模块之间的接口遵循统一标准,可以实现低成本的重构或重组。在SOA的技术框架下,可以把杂乱无章的庞大系统整合成一个全面有序的系统,从而增加企业在业务发展过程中应用系统的灵活性,实现最大的IT资产利用率。
3.1.2.5 美国国防部体系架构框架(DoDAF)[3,4]
随着信息技术的快速发展,武器装备信息化水平的不断提高,在各种武器系统及军事电子信息系统间建立紧密的信息联系,即实现不同系统之间的互操作,已成为武器系统及军事电子信息系统建设必须解决的重要问题。在这个领域,美军一直走在技术发展的前沿。
20世纪90年代,美军认真总结了以C4ISR为代表的复杂军事大系统的多年开发经验,于1996年颁布了C4ISR AF V1.0体系架构框架标准,为美国武器系统及军事电子信息系统的开发提供了具有跨时代意义的系统工程思想。1997年12月,美国国防部对这一标准进行了修订,并颁布了C4ISR AF V2.0标准。
在C4ISR AF V2.0标准中,美军将C4I系统的体系架构划分为三个组成部分:作战体系架构(简称OA)、系统体系架构(简称SA)和技术体系架构(简称TA)。
(1)作战体系架构是一种为完成和支持作战功能所需要的作战要素、任务分派以及信息流程的表述(通常是用图形表示的)。它定义了信息类型、信息交换频度,并用来说明信息交换所支持的任务。作战体系架构研究的内容包括:作战概念图、指挥关系图、活动模型、信息交换需求、需求能力矩阵和基本节点连接能力模型。
(2)系统体系架构是提供或支持作战功能的系统及其内部各要素或设备之间互连关系的一种表述(包括图形表示的内容)。它定义了关键节点、电路、网络、武器平台等的物理连接、位置及标识,规定了系统的组成和性能参数。系统体系架构是以技术体系架构中规定的标准和协议来满足作战体系架构的需求而构建起来的。系统体系架构研究的内容包括:确定系统的组成和各组成部分的连接关系;定义系统的约束和行为边界,绘制系统信息交换关系的叠加图;定义系统接口,绘制系统要素/接口图;给定系统的功能要求和系统的性能参数,预测系统满足作战需求的能力。
(3)技术体系架构是指导系统部件和构件的配置、相互作用、相互依赖的最低限度的一套规则,用来保证系统的一致性,以满足一组需求。技术体系架构必须要识别确认作业(服务)、接口、标准以及它们之间的关系,以便为基于工程规范的系统实施提供技术指南,建造共同的功能模块,开发生产线。技术体系架构研究的内容包括:信息处理标准、信息传输标准、信息建模标准、人机接口、信息系统安全标准以及正在形成的标准和规范。这些标准对于技术体系架构的建立都是强制性的和必须执行的标准。
上述三种体系架构之间的关系,可以表述为:确定作战人员的需求,提出各作战要素之间的信息处理和交换关系是作战体系架构对系统体系架构或技术体系架构的要求;确定一系列服务于系统的强制性标准、规则与惯例,建设系统各阶段的技术指导,以及引入新技术能力以服务于作战人员,是技术体系架构对作战体系架构或系统体系架构的影响;在已确定的强制性标准基础上叠加系统能力和作战人员的要求所需要的软/硬件设备,组成完整的系统体系,划清系统边界,形成系统体系架构。这三种体系架构之间的关系如图3.6所示。
图3.6 OA、SA、TA之间的关系
在C4ISR AF V2.0的基础上,美国国防部根据系统工程领域的技术进展和美国历年来军事系统研发经验,先后在2003年、2007年颁布了国防部体系架构框架(DoDAF)标准V1.0、V1.5,作为指导所有军事工程项目研发的系统工程方法论。
DoDAF定义了全景视图、作战视图、系统视图、技术视图等四类视图,从不同侧面来描述复杂武器装备系统。
(1)全景视图(AV):描述了体系架构项目的应用范围、目的等相关总体信息,包括上下文、摘要和综合术语字典。
(2)作战视图(OV):描述要支持的作战概念,包括完成作战任务的活动、作战要素、人员/组织之间的相关信息交换,定义交互信息的类型、频度、支持的作战活动以及信息种类,揭示作战能力和互操作性方面的需求。
(3)系统视图(SV):描述已有系统、待建系统和物理关联,以支持OV中记录的作战需求。
(4)技术视图(TV):系统部件/组件及其互联的技术标准,包含技术细节和技术标准演进的预测。
2009年8月,美军发表了DoDAF的2.0版。该版本扩展了前面版本的开发成就,提供关于网络中心战的体系架构信息,支持国防部网络中心战略,描述导向服务的解决方法,便利网络中心环境的创造和维持。DoDAF体系架构发展的重点也由以产品为中心转变为以数据为中心的方法。DoDAF 2.0版在原有全景、作战、系统及技术视图中,去掉了技术标准视图,用范围更广的标准视图来替代,包括了运作、业务、技术、政策、标准指南、约束和预测。
DoDAF 2.0版同时提供以下视图:
(1)能力视图:对能力的需求、交付时间和部署能力等进行规划;
(2)服务视图:对执行者、活动、服务以及他们为实现对应功能的交互进行建模;
(3)项目视图:描述运作需要与能力需求和实现这些需求的不同项目之间的关系,给出能力管理和国防采办管理过程之间依赖性的细节;
(4)数据和信息视图:规划体系架构框架下的数据结构和数据关系。
如今,美军在其各项系统工程实践中,严格按照《国防部体系架构框架》要求设计体系架构,构建武器装备体系或复杂武器系统的建设蓝图,在保证系统互操作、减少系统的重复建设、提高系统建设效率方面发挥着日益重要的作用。运用体系架构设计技术,能够保证在进行武器装备体系或复杂武器系统的需求分析和顶层设计阶段,科学、客观地描述作战需求,明确系统功能及相互间的关系。
3.1.2.6 英国国防部体系架构框架(MoDAF)[5,6]
英军认为,战略环境将出现新的变化,并对未来作战产生重要影响,主要表现在作战空间扩大并日趋复杂,冲突更加激烈并不可预知,导致作战方式的改变。夺取战争的胜利更加依赖于信息的开发与利用,对机动性和决策优势提出了更高的要求。
在深入分析未来作战环境和作战特点的基础上,英军为了实现与盟军伙伴间更有效的信息共享与信息利用,提高未来的作战效果,已提出实施“网络赋能能力”计划(简称NEC)。网络赋能能力是指将决策者、传感器与武器系统相互连接在一起,使信息快速传送到需要的地方,同步实现精确军事打击效果的能力。英军把“网络赋能能力”作为与盟国、盟军互联互通的关键,并考虑到在很多主要军事行动中,英军都是美军的首要盟军伙伴,更要力图跟上美国的转型步伐,将实现与美军的互联互通放在优先的地位。为此,英国国防部成立了国防部体系架构框架(MoDAF)小组,制定英国国防部体系架构框架,以便严格规范复杂系统的采办,科学分析现有的作战系统,更好地实现新、旧系统的集成。MoDAF V1.0版已于2005年8月31日正式发布。MoDAF借鉴了美军DoDAF的主要成果,增加了“战略视图”和“采办视图”,并对作战视图和系统视图做了若干修改,如图3.7所示。该框架既注重与盟军的兼容互通,又考虑了本国的作战任务和经济基础。MoDAF同时也影响了DoDAF的发展,DoDAF 2.0版也大量借鉴了MoDAF的思想。
图3.7 MoDAF视图
(1)全视图(AVs):是体系架构的顶层描述,包括使用范围、使用者、时间跨度,以及为有效搜索和查询体系架构模型提供所需的其他基本信息。
(2)战略视图(StVs):用于支持对现有军事能力分析和优化的各种战略。战略视图进一步细化了各种军事能力的从属关系,以便整个装备计划中对其进行有效的折中和权衡。战略视图从战略的高度描绘了系统所具备的能力,是MoDAF在DoDAF基础上新增的视图之一。
(3)作战视图(OV):描述了完成作战使命所需的任务与活动(包括平时和战时作战活动)、作战组织指挥关系、作战节点及连接关系,以及信息交换需求。作战视图可用于作战使命“全寿命周期”中的多个时间节点,包括开发用户需求、形成未来作战方案、支持作战计划的制订等。与DoDAF相比,MoDAF对高级作战概念图进行了扩展。
(4)系统视图(SV):描述支持作战任务的各种功能系统(主要但不仅仅是通信和信息系统)的功能、组成、相关关系以及通信连接关系和接口。系统视图用于将系统资源与作战视图关联起来,主要用途是开发满足用户需求的系统方案,并提出合理的系统需求。与DoDAF相比,MoDAF对系统通信描述进行了扩展。
(5)技术视图(TV):描述适用于体系架构各方面的标准、规则、政策和指南。技术视图的内容并不完全是技术方面的,它既适用于各种系统(如各种标准和协议),也适用于各种作战行动(条令、标准使用程序和战术技术程序)。
(6)采办视图(AcVs):与战略视图一样,是MoDAF新增的内容。采办视图用于描述系统建设“全寿命周期”计划的细节。通过采办视图,可以确定项目与计划之间的相互影响,以及整合防务研制过程中的各种采办活动。
3.1.2.7 北约体系架构框架(NAF)[7]
2002年,北约C3委员会认为需要开发一个与美国“网络中心战”和英国“网络赋能能力”概念相对应的北约概念,于是有了“北约网络赋能能力”的概念。为提高欧洲盟军司令部(ACE)与大西洋盟军司令部(ACA)(这两个部门于2003年合并,更名为盟军作战司令部(ACO))之间以及北约成员国之间C3I系统的互操作性,北约C3委员会制定了一系列的政策,如“北约C3I互操作性政策”、“北约互操作性管理计划(NIMP)”。其中,“北约互操作性管理计划”提供了开发C3I系统体系架构框架的有关指南。
2003年北约参考美军DoDAF制定了C3I系统体系架构框架(NAF)。该框架提供了描述和开发体系架构所需的规范和模板,确保盟国在理解、比较和整合体系架构时采用通用的原则,是北约强制要求C3I系统执行的体系架构框架。
从2000年11月北约C3委员会第一次推出北约C3I系统体系架构框架(NC3SAF)至今,北约已陆续推出多个版本的体系架构框架。最早的NC3SAF基本上是以美军的C4ISR体系架构框架为基础,后续的版本中根据北约自身的特点和需求,对原有版本的内容不断修订和升级,北约体系架构框架的第二版,是在2002年到2004年之间开发,并于2004年8月获得批准,最新的NAF 3.0版本发布于2007年。NAF 3.0为北约及其成员国开发和描述体系架构提供一系列规则、指南和产品,确保所开发的体系架构能够进行比较和集成。在NAF 3.0版本中,主要从七个视角来为体系架构提供具有整体性、一致性和连贯性的描述,同时又以每个视角规定了若干产品来描述北约体系架构中每个视角的特定属性。这七个视角分别是北约作战视图(NOV)、北约系统视图(NSV)、北约技术视图(NTV)、北约全局视图(NAV)、北约服务视图(NSOV)、北约能力视图(NCV)和北约计划视图(NPV),如图3.8所示。
图3.8 北约体系架构NAF
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。