数据资源服务平台

国外研究进展_海底科学观测的国

12.1.1 美国OOI海洋观测计划

美国OOI海洋观测计划包括全球节点、区域节点和近岸节点。CI集成了OOI的各类观测节点、数据存储资源、计算资源以及通信网络，目的是为科学用户提供一个简单易用的信息系统，其主要目标包括（Brasseur，2010）：

·实现传感器、仪器平台、主干网之间数据和指令的交互；

·能获取科学数据和其他数据并统一集成到OOI的框架体系中；

·实现科学数据和数据产品的存储、访问、转换、分析和可视化；

·集成和存储派生的数据产品和海洋数值模型产生的数据；

·实现对复杂海洋长期观测系统的规划设计和控制；

·实现对海洋观测系统的交互控制和运维管理。

CI通过提供相应的软件服务和用户界面来实现上述目标。此外，CI提供了基于消息和面向服务的通信、管理和安全体系集成框架，还提供了一种物理上分散的分布式处理和逻辑上统一的信息系统集成机制。本节将主要从CI的需求分析、功能设计和关键技术及其管理和运行机制等方面内容进行介绍（Consortium for Ocean Leadership，2008a， 2008b；Farcas et al.，2008；Chave et al.，2009，2011；Arrott et al.，2009，2011）。

1.需求分析

需求分析是软件开发过程中最基础、最重要的环节，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。OOI的CI需求是CI设计团队在与海洋科学家、工程技术人员和相关用户充分沟通的基础上提出来的，从资源管理、数据管理和分析、海洋建模、可视化、计算与处理、传感器和仪器接口、任务规划与控制、应用集成和外部接口、用户界面设计、安全性、质量属性、科普教育、文档管理及发展进程等15个方面详细分析了CI设计过程中需考虑的220多项功能需求，具体内容请参考文献（Elizabethetal.， 2008）。CI设计团队根据各项功能特点，将需求划分为必要性、重要性和可选性三个层次。这些需求分析内容是设计和开发CI软件系统的基础，能有效地指导软件开发人员设计软件功能模块，确保CI软件系统的功能、性能等指标能满足不同用户需求。

2.总体框架

从CI提供的服务类型上划分，CI可分为应用服务和基础服务两大框架（图12-1）。其中，应用服务框架包括信息感知和采集（Sensing&Acquisition，SA）服务、数据管理服务（Data Management，DM）、数据分析和集成（Analysis&Synthesis，AS）服务以及观测规划和实施（Planning&Prosecution，PP）服务，基础服务框架包括数据管理（信息分发）服务、公共执行基础框架（Common Execution Infra-structure，CEI）服务。应用服务面向CI终端用户，而基础服务则是服务于CI的基础设施管理，同时也是应用服务的基础，为终端用户应用程序运行提供支持。从图中可看出，CI的数据管理服务被分成科学服务和信息发布两部分，分别满足科学研究和公众对OOI海洋观测数据的需求（Consortium for Ocean Leadership，2008a，2008b；Chave et al.，2009）。CI提供的6类服务，通过6个相应的系统或功能组件来实现，并通过相关接口与用户及外部资源进行交互（用八边形表示并与外部环境资源相连接），如图12-2所示。无论在何处部署，功能组件都能为OOI综合观测网提供所有的基础设施和应用程序支持。

图12-1 CI服务网络（Consortiumfor Ocean Leadership，2008a）

此外，在CI总体设计过程中还考虑以下因素：

·CI是服务科学和创新研究，因此CI的设计必须以科学目标为导向；

·CI的系统工程和集成过程需符合系统工程国际委员会（INCOSE）和EIA632“系统工程过程”的标准；

·CI的系统工程和集成过程需符合相关机构已有体系结构框架；

·CI必须符合国家安全和法律规定；

·CI必须有效管理CI与全球、近海、区域三个子系统的软硬件接口；

·CI运作理念需遵循现有的相关政策和程序。

3.功能设计及关键技术

CI以服务网络（Services Network）的形式向用户提供软件系统的各类功能，本小节介绍CI提供的六大类核心服务网络的内容及其总体设计，并简单介绍CI服务设计与实现过程中涉及的关键技术。

图12-2 CI功能容器（Consortium for Ocean Leadership，2008b）

(1）感知和采集服务网络

感知和采集服务网络（Sensing&Acquisition Services Network，SASN；Consortium for Ocean Leadership，2008a，2008b；Chaveetal.，2009）实现对仪器和观测平台的访问和管理。在功能上，负责接收、缓存和传输数据，交互控制仪器和管理观测平台等。SASN是CI与OOI仪器连接的主要接口，也是CI与IOOS（Integrated Ocean Observing System）、NEPTUNECanada等外部数据源通信的接口。SASN通过特定的适配器与供应商提供的软硬件进行交互。

图12-3是SASN功能服务中仪器设备的控制指令流、数据流及各个模块之间的交互视图。首先，观测系统管理组件（Observation Management）根据需将仪器设备的控制指令发送到观测平台Agent（Platform Agent），并由仪器Agent（Instrument Agent）将指令转发到具体的仪器设备（Instrument）。仪器设备根据指令完成数据采集等工作，并将传感器数据及其状态信息返回到SASN数据处理组件（Data Processing）和观测系统管理组件。同时， SASN将初步处理的传感器数据和仪器状态信息分别发送到数据管理服务网络和规划执行服务网络中。

仪器Agent：负责接收从平台Agent发送仪器的转译命令，并从外部源更新仪器时间，检测资源冲突（如版本或驱动程序冲突）等。

仪器监视组件（Instrument Supervisor）：接收仪器Agent传输的状态信息和观测数据，并根据状态信息进行设备诊断和评估，主要负责仪器故障检测和恢复，并提供告警和警报。

观测平台Agent：负责协调和管理搭载在观测平台上的所有仪器，以确保设备安全正常运行。

图12-3 感知和采集服务网络（Consortium for Ocean Leadership， 2008a）

支撑SASN的技术包括：Iaa S（Infrastructure as a Service，Iaa S）、面向java的动态模型系统（OSGi）、Antelope、SIAM、MBARIPUCK及Inter Mapper等。

(2）数据管理服务网络

数据管理服务网络（Data Management Services Network，DMSN；Consortium for Ocean Leadership，2008b；Chave et al.，2009），负责接收观测数据及其元数据并存储到数据库中，包括DMSN（科学服务）和DMSN（信息分发）两部分内容。DMSN支持结构化数据、数据格式转换及本体支持下的语义转化，能提供基于元数据的各类信息查询。DMSN处理的信息内容包括观测数据、派生数据产品、元数据和其他观测平台操作的信息资源（如辅助工具信息、用户身份信息等。DMSN采用分布式交换框架的数据处理模式，提供了数据存储、发布、远程访问、事件探测、数据分析和可视化功等功能。

如图12-4所示，DMSN（科学服务）由数据获取（Ingestion）、转换（Transformation）和展现（Presentation）等三个核心服务组成，此外还包括数据存储服务和数据编目服务。DMSN通过信息交互服务（Exchange）与CI其他功能服务交互。

数据获取服务：主要负责原始数据的解析，原始元数据的提取和记录，并在其他子系统之间建起桥梁，为其提供相关数据产品。

数据转换服务：负责处理数据的格式和结构转换，数据校正和QA/QC处理，外部元数据提取、验证和确认。

数据展现服务：提供浏览/导航具体数据产品和基于元数据或数据内容搜索/查询的功能，用户可指定各种构造子集或聚合约束来满足数据产品的检索需求。

数据存储服务：根据OOI策略，负责数据的复制、存储和归档及备份到分布式数据仓库中。采用实时存储和长期存储相分离的方式存储数据，以优化信息存储和信息访问及元数据的处理等过程。

数据编目服务：针对数据获取和检索，提供编目、索引和元数据处理功能，还提供了所有数据实体的所有权、作者权、关系及通信息等元数据信息。

信息交互服务：CI信息流转、系统间交互的桥梁，主要职责是通过适当的路由实现基于订阅方式的数据访问和数据传输。

图12-4 数据管理服务网络 （Consortium for Ocean Leadership， 2008a）

图12-5 数据管理（信息分发）服务网络（Consortium for Ocean Leadership，2008b）

图12-5描述DMSN（信息发布）主要由数据存储服务（Preservation）和数据目录服务（Inventory）组成，这两类服务提供的功能与DMSN（科学服务）相应的服务类似。根据OOI相关政策，DMSN（信息发布）提供通用信息模型（包括数据和元数据模型），实现自动化信息发布和通用访问。信息模型的包括通用信息（如文本描述）和专业信息两类，专业信息指服务网络（如海洋数据和元数据），多种信息表示、存储和数据资源及它们之间的本体和映射关系。

支撑DMSN的技术主要有VSTO语义框架，Net CDF，Nc ML，SPARQL，URIQA， MMI，OGC服务，Open DAPHyrax Server，IRODS，My SQL，cluster等。

(3）分析和集成服务网络

分析与集成服务网络（Analysis&Synthesis Services Network，ASSN；Consortium for Ocean Leadership，2008a，2008b；Chaveetal.，2009），支持多种数据和数据产品的生产、处理、分析和可视化，事件监测、数据同化及模式的集合和执行，也提供虚拟协作平台用以实现虚拟观测网、虚拟教室和虚拟实验室。描述ASSN的工作流管理服务（Workflow Framework）、事件检测服务（Event Detection Framework）、数据同化和模型集成服务（Data Assimilation and Model Integration Framework）、虚拟协作管理服务（Virtual Collaberation Management）和交互分析和可视化服务（Interactive Analysis and Visualization）等核心服务及其信息交互情况。各组件能根据户提供的流程、工作流、应用程序和工具以插件形式来执行指定的功能，并通过信息交互服务（Exchange）进行数据、消息传递和数据生产。

数据同化和模型集成服务：包含观测过程和事件预测的数值模式，以及应用实时数据对数值模式进行数据同化，并发布数值模型产生的预报产品。

事件检测服务：通过信息交互服务（Exchange）在DMSN中定义事件和建立触发条件，并为DMSN提供了基于主题模式的识别事件，以及事件检测和事件分类信息。

工作流管理服务：是CI中的数据流引擎，具有定义、集成和执行用户工作流的功能。这些工作流根据特定需求而定义，如数据的QA/QC处理、事件检测及模型集成等。

虚拟协作管理服务：提供定义虚拟观测平台、实验室和教室的基础，分布在不同地方的人员使用同样的物理和虚拟资源来进行协作研究，其过程包括：项目首席定义项目，邀请他人参加合作，选择可用资源，管理项目关系和资源使用政策，使用数据处理、分析及可视化工具，定义工作流及发布公众研究成果。

交互分析和可视化服务：该服务负责向用户提供一组标准的数据分析和可视化工具。用户通过交互的可视化界面来访问ASSN（数据分析和集成服务），并与事件检测服务、数据同化和模型集成服务相交互。

图12-6 分析和集成网络服务（Consortium for Ocean Leadership， 2008a）

支撑ASSN的技术有Matlab，Kepler，Pegasus，Open Scene Graph，IDV，OSSIM Planet及Google Earth&Maps等。

(4）规划和实施服务网络

规划和实施服务网络（Planning&Prosecution Services Network，PPSN；Consortium for Ocean Leadership，2008a，2008b；Chave et al.，2009），通过利用集成网络中传感、建模和控制资源来支持资源组网和资源自治，提供广义资源的规划和控制活动，这些活动会被应用于多目标观测项目的规划、进度安排和执行，其核心服务如图12-7所示。

交互观测基础设施服务（Interactive Obeservatory Facility）：在ASSN提供的虚拟协作管理和交互组件的支持下，该服务提供资源设计、组装和操作配置等服务，包括OOI的观测规划、测试和实施等环节，也为科研实验提供定义、组合和安排多仪器观测服务。

事件响应框架服务（Event Response Framework）：从DMSN中订阅资源获取管理规则、信息处理和事件，提供自动的和专业的审查事件和过程，以此更新仪器和移动观测平台的观测任务，将新的观测请求发送到资源规划服务。

资源规划服务（Resource Planner）：资源约束模型将资源的状态条件及在其上执行的活动进行抽象，完全由资源提供者和资源监测器进行处置。资源规划如同约束求解，以资源请求为输入，以资源使用计划为输出。另外，资源规划的也有职责和单个资源及其相关资源进行协调使用，所得到的资源协议和资源使用计划及相应的操作和控制将由资源使用控制器服务去执行。

规划知识库服务（Plan Repository）：一个基于DMSN用以存储和管理观测计划及相关信息的知识库实例，如参数配置、资源（再）配置及自主行为活动。

图12-7 规划和实施服务网络（Consortium for Ocean Leadership， 2008a）

资源使用控制器服务（Resource Use Controller）：负责操作由资源规划服务决定的计划。资源使用控制器服务将资源使用计划和服务协议作为输入，将资源使用计划的控制或触发状态及活动修改作为输出。

故障监控服务（Falut Monitor）：用于监控资源状态，并提供故障分析结果给资源使用控制器服务。

支撑PPSN的技术主要有ASPEN，CASPER，MOOS和MOOS-Iv P等。

(5）公共执行基础框架

公共执行基础框架（Common Execution Infrastructure，CEI；Consortium for Ocean Leadership，2008a，2008b；Farcas et al.，2008；Chave et al.，2009）提供在任何地点独立于执行环境的规划和执行任何计算的方式。CEI为OOI提供了虚拟化的计算资源基础设施，包括执行资源配置、远程操作管理和流程执行，支持软件包功能分解、部署、实施、集成以及执行引擎和特定用户目的的环境。

图12-8是CEI的一个分解视图，其核心服务是计算调度程序（Compution Scheduler）。计算调度程序接收OOI中那些需由信息交换服务处理的服务的服务协议，这些服务协议包含处理请求及在计划执行中的精确的条件。根据协议，计算调度程序决定了处理规划，并触发计算控制器（Computation Controller）启动处理进程。计算控制器负责计划和服务协议范围内指定执行计划，它提供了计划的和正在进行计算的状态。故障监测（Fault Monitor）负责监测任何正在运行的进程，并通过信息交换服务向服务请求者提供故障分析结果。

操作单元（Operational Unit）在处理时是独立的、自动生效的，可在有需求时实例化，没有需求时自动失效。执行引擎（Excution Engine）是一个特殊的操作单元，它会等待需处理的执行进程，而计算调度程序决定进程如何执行引擎上运行。为了执行进程，计算调度程序从进程定义知识库（Process Definition Repository）获取进程定义信息，并与执行引擎协同委托执行相关进程。

支撑CEI的技术有Condor，Amazon EC2，Nimbus，Cohesive FT弹性服务器平台技术和Teragrid Gateways等。

图12-8 公共执行基础框架（Chaveetal.， 2009）

(6）公共运行基础框架

公共运行基础框架（Common Operating Infrastructure，COI；Consortium for Ocean Leadership，2008a，2008b；Chaveetal.，2009，2011）提供统一的用户身份管理、程序接口，同时提供对各种资源的生命周期和访问的统一管理，实现了基于消息交换和服务编排的集成策略。

COI整合了其他服务网络，能使数据在CI不同服务间中传输，实现子系统的松耦合，隐藏了它们的复杂性并能高效集成，使子系统服务能组合起来处理复杂的交互操作。图12-9描述了COI的核心部件与各子系统之间的通信。

身份管理服务（Identity Management）：提供身份验证和授权服务，确保OOI设施和CI组件间建立可信、可靠的链接链。

管理框架服务（Govermance Framework）：将OOI管理机构及其他相关机构制定的规范、政策、与不同资源相绑定，通过信息交换服务（Exchange）与身份管理服务紧密耦合，有效实施在CI中执行相关规范、政策。

状态管理服务（State Management）：存储和管理了所有的临时状态信息，这些信息包括身份管理、策略执行及正在进行的对话等。

资源管理服务（Resource Management）：整合了OOI服务集中所有的资源，可分为资源整合服务、资源生命周期服务、资源协作服务及资源仓储服务。资源生命周期服务提供了管理资源从发展到退役整个生命周期的手段；资源协作服务在基础设施和共享资源之间建立服务；资源仓储服务存储了所有资源的相关信息。

服务框架（Service Framework）：存储资源及其相关描述信息，以及不同资源之间的关系信息，以便于资源的检索和订阅。

支撑COI的技术有Rabbit MQ，Spring，MULE，Comanage，Shibboleth，Globus Toolkit，My Proxy，Sun XACMLImplementation等。

图12-9 公共运行基础框架（Chave et al.， 2009）

4.CI实例：OOIData

OOI公开发布所有用于科学研究的基础数据，用户无需支付任何费用可使用。全球用户都可使用数据在线系统（OOIData）访问OOI发布的数据。OOIData提供了Data Portal，THREDDSServer，Raw Data Archive，Cruise Data，Live Video和Data Product等软件系统，用于访问不同类型的数据。关于OOIData系统的详细功能，可登录OOIData进行体验。

Data Portal（数据门户系统）以单点登录的方式，向用户提供OOI的观测数据。用户可按照观测区域、观测内容等方式浏览、下载数据，系统还提供数据分析、可视化等功能。

OOITHREDDSServer为经过科学监督委员会（Science Oversight Committee，SOC）确认的平台提供经过预处理的初步数据集，这些数据主要是全球海洋观测系统（Global Ocean Observing System，GOOS）提供。通过THREDDS服务器提供的OPe NDAP和Net CDF服务，可获取任何已通过评估的数据及其元数据。

OOI所有观测平台和仪器采集的原始数据（包括水声和地震观测数据）都存储在Rutgers大学的NAS文件系统中，这些OOI原始数据可通过数据存档系统（Raw Data Ar-chive）来访问。

Cruise Data（走航观测数据）用于管理和发布OOI的走航观测数据，数据按照航次进行数据编目，供用户浏览和下载。

用户可通过Live Video（视频直播）访问OOI海底现场视频数据。在距俄勒冈海岸约400km海域的1600多米水深处，部署的海底原位高清摄像机通过OOI光缆实时传输视频流媒体数据。每隔3个小时，用户可通过Live Video在线观看一个持续约14分钟的海底热液现场观实时观测视频。

通过Data Product（数据产品系统），用户可访问由观测数据派生的产品数据。这些派生的数据产品是通过特定的数据处理算法或模型对OOI采集到观测数据做进一步处理后得到的数据，可分为海气表面、海底表面/深部和水柱等三大类，超过200小类的数据产品。

5.管理和运行机制

2004年起，美国国家科学基金会（NSF）建立了一个海洋联合机构项目办公室（Joint Oceanographic Institutions，JOI）来负责协调规划OOI项目。JOI要求OOI的牵头单位必须是学术机构，以确保较高的专业水准。MARS系统将作为OOI项目的测试基地，在OOI项目建设过程中发挥重要作用（Consortium for Ocean Leadership，2007）。

通过与NSF的合作协议，COL（Consortium for Ocean Leadership）和它的主要合作机构UW，USCD，OSU，WHOI和Scripps将组成一个联合的项目组来实施OOI。该项目组的职责是设计OOI的开发和运作框架，与项目咨询机构和NSF进行磋商，确保OOI得到专业地管理和顺利实施。项目组也对项目风险进行评估和管理，在经费预算范围内完成OOI建设内容（Given&Banahan，2007；University of Washington，2007）。

图12-10是CI的建设进度安排。与NEPTUNE的DMAS软件系统开发模式一样，CI的各个子系统也采用螺旋式软件开发模型，分五个阶段进行开发和设计。CI设计的第一个阶段将提供基本的数据感知和采集、数据管理功能，以及初步设计与实现公共运行基础框架（COI）。这一阶段CI提供的功能主要用于支持主干网和岸基站的测试。这些子系统的功能在CI后续的第二和第三阶段设计中将得到进一步加强和完善，并陆续增加分析、集成、规划实施，及实现公共执行基础框架（CEI）的系统功能服务。CI是整合OOI资源的关键系统，所以它的功能开发与设计对OOI观测系统的建设和全面运行至关重要。

图12-10 CI建设进度安排（University of Washington，2007）

图12-11描述了OOI的运行框架以及参与OOI项目的不同工作组、组织机构。负责OOI网络系统集成的COL主要由设施管理团队（FGG）和设施运行团队（FOG）两个团队组成。FGG确保OOI运行及逐步实现它的科学目标，FOG负责OOI网络操作和运行。

CI的运行管理由CIIO（CIImplementing Organization，CIIO）负责，如制定元数据政策、记录并报告软件运行的Bug、数据错误等。在对CI的管理过程中，CIIO会首先提出CI的管理程序和维护措施（政策），然后提交FOG进行审核，审核通过之后，CIIO会依据其制定的相关政策管理CI。

图12-11 运行管理框架 （Consortium for Ocean Leadership， 2007）

从数据来源角度看，OOI的数据可分为公共数据、项目研究数据和商业数据三大类（Consortium for Ocean Leadership，2007）：公共数据为OOI采集的基础数据（例如基础的气象、环境数据，系统数据等）；项目研究数据为独立的科研团队在OOI框架下进行特定的项目研究中产生的数据；商业数据为在私人资金资助下，采集用于商业目的的数据。

OOI数据政策和数据管理的指导原则是，用户可通过互联网近实时地免费访问大部分高质量的数据和数据产品。特殊地，对于OOI的项目研究数据，项目PI（Principal Investi-gator，PI）可申请在头一年中优先使用该项目获取相关的数据，在此之后，所有这类数据也需公开发布，供其他用户公开访问。另外，对OOI的商业数据，用户则需支付一定的费用才能获取相关数据。

在OOICI设计的过程，有一些经验教训是值得我们借鉴的。在CI设计的初始阶段，考虑到UCSD大学在信息技术、海洋科学以及海洋生物学等领域的优势，2007年JOI委托UCSD大学负责实施OOICI（Douglas，2007）。Rutgers大学于2011年参与CI建设工作，负责OOI科普教育及公众参与软件的架构设计（Kerry，2011）。UCSD大学电子与信息技术研究院（Calit2）具体负责管理CI项目，并协同Scripps海洋研究所、圣地亚哥超算中心（SDSC）共同建设CI。同时，MIT，USC，JPL和WHOI等院校和科研机构的专家以及Raytheon公司、Boulder实时技术公司和Triad项目管理服务公司等3家企业也参与了CI的建设工作（Douglas，2007）。

但是，当OOI的观测系统都部署到位时，CI的建设却碰到了钉子。由于UCSD设计的CI框架过于庞大，设计要求高，而OOICI建设的经费又较比当初预算减少了很多，严重影响了CI的建设。OOI的其他项目组抱怨，他们的观测设备已经在海底运行工作了，但CI的软件系统却无法将及时处理从海底光缆传输回来的数据，采集的数据不能得到及时应用和共享。甚至出现了这样的情况，有的项目组由于研究需要，不得不临时把数据传输到华盛顿地震研究所的数据中心（Witze，2014）。

COL的专家们经过评估，认为CI的建设已经严重下滑，建设进度远远滞后。因此，在UCSD已经耗费了3700万美元用于CI设计之后，COL建议OOI终止与UCSD的CI建设合同。2014年11月1日，UCSD的CI研究团队于切断了CI与OOI所有仪器设备的连接，并将计算机服务器设备等打包运输至Rutgers大学。随后，OOI投入1180万美元，与Rutgers大学签订了为期2年的研究合同，由Rutgers大学负责继续进行CI建设（Witze， 2014）。Rutgers大学在非常紧张的时间下，完成了CI的数据管理系统设计。

COL的专家们承认，相对于UCSD大学设计的复杂的、先进的CI系统，Rutgers大学设计的CI仅仅是基础的软件系统，功能相对弱一些，比如，目前其控制水下设备的能力相对有限。COL的专家甚至打趣地说：“原来的CI设计像是一辆法拉利，而现在造出来的却是一辆宝马汽车。”但是，不可否认，Rutgers大学设计的CI包含了必备的核心功能，满足了OOI的基本要求（Witze，2014）。同样地，CI建设任务由最初的UCSD大学转由Rutgers大学负责，这一调整措施确保了OOI能在现有经费预算条件下按时完成系统建设工作。

因此，在CI的设计过程中，我们必须汲取OOICI设计的经验和教训。主要是：负责CI设计的大学或科研机构，必须要在海洋科学领域和信息技术领域都具备优势。同时要联合领域内其他科研机构的专家和技术人员，并充分利用科研机构现有的设施和设备。此外，还要积极吸引拥有先进信息化技术的企业参与CI建设工作做好顶层设计，采用总体规划、分步实施的策略，避免一蹴而就，要有计划、有步骤地完成阶段性任务，确保在有限的时间、有限的经费预算下完成有限的目标。成立CI设计专家委员会，负责全程监督、评估和指导CI的建设，确保能够围绕既定目标顺利开展CI建设工作。CI的建设进度关系着海底观测网的整体建设，因此，CI的建设必须严格按进度安排进行，甚至可以提前进行研究，避免出现OOI已部署的观测系统却需要等待还处于研发状态的CI软件来处理数据的情况。

12.1.2 加拿大海底观测网

1.需求分析

加拿大海底观测网的CI称为数据管理与存储系统（Data Management and Archiving System，DMAS）。从科学研究与应用出发，DMAS功能设计需实现以下三个基本的目标（Pirenne&Guillemot，2009；Barnes et al.，2013）：

·DMAS应能接收和处理海底观测网各仪器采集的数据，并实时/近实时地向用户分发数据。

·DMAS应能远程控制部署在NEPTUNE上的观测仪器与设备。

·DMAS为NEPTUNE提供一个长期的、安全的数据存储平台，以及一个能使海洋科研人员方便访问数据的应用系统。

为了实现上述目标，在最初的总体设计阶段，从用户需求和系统需求两方面对DMAS进行了分析。

DMAS用户需求分析的内容涵盖总体需求、用户交互需求、数据存档需求、系统接口需求和仪器控制需求等5个方面共36项具体需求。DMAS系统需求描述了系统必须具备和执行的功能，以满足不同用户能实现其需求的要求。具体内容请参考文献（Norman&Séverin，2002）。

2.总体设计

DMAS的核心是企业服务总线（Enterprise Service Bus，ESB；Data Management and Archiving System Team，2006；Barnes et al.，2007）。ESB是一种面向服务的体系架构，是一个集中的、可扩展的、容错的服务消息框架，它提供了一个透明的手段，通过不同的通信协议耦合各种不同的服务。此外，ESB还提供了一个共享的消息层，使企业应用程序、服务和组件可连接和通信。ESB具有内置的错误恢复机制，能处理消息传递失败、可拓展性、消息重复和网络故障等问题。ESB这些特性是DMAS软件架构的基础。

DMAS同样支持基于服务编制（orchestration）和编排（choreography）的Web服务技术，使科学家能写出复杂的事件监测和响应算法。此外，应用DMAS提供的Web服务，科学家们能从DMAS的数据仓库中获取海量数据，并使用自主研制的软件或开源的软件系统来执行复杂的数据分析。

DMAS的主要功能模块包括数据采集与控制（Data Acquisition and Control）、基础设施监视和控制（Infrastructure Monitoring and Control）、数据存储（Data storage）、数据检索与展示（Retrieval，displaying of information）、事件监测与响应（Event Detection and Reac-tion）和用户管理（User management）等（Benoit，2005），每个模块的包含的具体功能如图12-12所示。

DMAS的架构可分为四层，即设备层、表现层、应用层和资源层，如图12-13所示。设备层包括智能设备的计算元件和非智能设备的适配器。表现层主要负责信息的格式转换和对外发布。应用层重新组合来自ESB和Web应用程序的所有服务。资源层包括所有与资源相关的服务，例如数据库及其平台等。

图12-12 DMAS功能模块设计

图12-13 DMAS架构图（Data Manage-ment and Archiving System Team，2006）

图12-14是DMAS应用于VENUS项目的系统部署视图。从视图可看出系统由三个基本的组成部分，即数据中心（UVic Data Centre）、岸基站（IOSShore Station）、水下节点（Underwater）及其三个并行的数据流组成。DMAS数据流（绿色箭头）包括从仪器端收集科学数据并向外部进行分发。军方（涉密）数据流（红色箭头）包括来自水听器阵列的敏感数据和流向军方涉密系统。基础信息流（蓝色箭头）包括与水下节点设施相关的数据。三个独立的数据流在网络层以网络交换机控制的虚拟局域网实现，交换机同时也提供各部件之间的连接功能。

数据中心负责收集和存档所有数据，同时也提供给用户搜索和获取数据的界面。岸基站以数据库或数据文件形式缓存仪器采集的数据，然后将数据转发到数据中心。一些用于特殊数据处理的计算机系统和军方切换系统同样部署在岸基站。此外，每个岸基站都有一个GPS时间服务器，可向仪器设备提供精度达微秒级的授时服务。水下节点是指各种水下的组成部分，包括仪器、海底主基站和SIIMs。由于水听器数据可能含有敏感信息，为了满足军方的要求，军方数据流是独立隔离的。这些数据暂时不宜对外公开，将被传输到军方的安全系统，经军方处理后，部分数据也可能会再返回到DMAS中。

图12-14 DMAS部署视图（Data Manage-ment and Archiving System Team，2006）

3.DMAS实例：Oceans2.0

Oceans2.0是NEPUTNE信息化建设的一个重要成果（Pirenne et al.，2014）。Oceans2.0是在DMAS需求分析的基础上，依照DMAS设计理念进行开发设计的，驱动了多元、海量数据全年不间断地采集、管理和再分发。除了核心的数据接收与处理功能， Oceans2.0也提供数据的存储、质量控制、校准和可视化功能，并提供直观、便于操作的系统界面，以支持全球用户应用数据。基于灵活性和扩展性的设计理念，Oceans2.0不仅可集成多源异构的海洋观测数据，也便于定制以满足各种终端用户需求的应用。

Oceans2.0是一套功能强大、高效且智能的数据处理和分析软件系统，它将NEP-TUNE核心组成部分有效地融为一体。在Oceans2.0所有用户中，包括：

·高级用户：控制和监视NEPTUNE的设备；

·管理员：控制和监视Oceans2.0运行；

·科学家：访问所有的数据；

·教育工作者：访问用于教学目的而定制的数据；

·普通公众：访问图像、视频和其他公开数据产品。

Oceans2.0不但能管理来自NEPTUNE的数据，为研究人员以及用户提供近实时数据，且能对NEPTUNE的传感器、观测平台等基础设施实现交互控制。此外，科研人员和其他用户还可通过这个平台进行合作互动，协同完成科学研究。用户通过标准的浏览器即可访问Oceans2.0的Web页面，无需安装或维护任何基于客户的软件或插件。

图12-15 Oceans2.0关键组件（Ocean Net-works Canada，2015）

Oceans2.0是基于Web2.0技术，采用面向服务架构EBS企业服务总线技术开发，为模块化、松散耦合、以组件为基础的系统，如图12-15所示。基于这种架构，Oceans2.0提供了以事件为驱动的和“即插即用”的系统，可根据用户单位需求扩展（调整）系统模块。另外，该系统将所有关键组件隔离在物理安全的私有网络中，避免系统恶意访问或攻击，且具有很强的容错能力，建立系统和数据异地备份中心，确保系统和数据的安全。

从软件系统功能角度来看，Oceans2.0体现以下诸多特征（Ocean Networks Canada， 2015，2016）：

·经过验证的、可靠的、可扩展的数据管理和仪器控制系统；

·提供最先进的工具和功能来提升海洋研究和业务决策能力；

·高效地收集/归档传感器数据，以支持短期和长期的时间序列研究；

·24/7/365全天候数据采集和接近实时发布多源的、海量的数据；

·支持数百种海洋仪器，涵盖大部分常见80余种海洋仪器；

·同时管理有缆以及自治/离线仪器（浮标、滑翔机和水下机器人等）；

·通过互联网，支持交互式配置、管理和监控所部署的传感器和观测平台；

·允许交互式远程控制部署的仪器，包括摄像机、海底爬行器等；

·记录跟踪观测系统的所有变化和事件；

·可处理和显示数据，建立观测时间表，事先确定事件监测和响应程序；

·先进的视频预处理、归档、注释和搜索功能；

·通过数据解析、校准、推导和QA/QC来丰富和提高收集的数据；

·直观、友好的用户界面，简化传统的复杂任务，便捷的数据访问模式；

·所有用户可在全球范围内通过互联网访问数据。

关于Oceans2.0的具体功能，可访问http：//dmas.uvic.ca/home登录Oceans2.0系统详细了解，依据用户所具有的权限进行相关功能操作。

4.Smart Oceans Systems TM

加拿大海底观测网在CI的基础上推进智能化海洋信息系统建设，以提高海洋研究、管理和决策能力。2014年，Western Economic Diversification机构和IBM（加拿大）共同投入2000多万美元资金，用于支持ONC（Ocean Network Canada）研发全球领先的Smart Oceans Systems TM（智慧海洋系统）。为了支持Smart Oceans Systems TM研究，加拿大交通部过去几年已向ONC提供了2000万美元用于NEPTUNE的运行和维护（Ocean Net-works Canada，2013；Ocean Networks Canada，2014b）。据ONC估计，到2020年，智慧海洋信息技术的全球市场份额将达到60亿美元（Ocean Networks Canada Media Relations， 2014）。此外，ONC还得到CANARIE（Canadian network for the advancement of research industry and education）的60万美元资助（Ocean Networks Canada，2013），主要用于研究能在移动终端上运行的Oceans2.0产品和海洋事件快速监测系统，并作为NEPTUNE增强的数据分析系统集成到Smart Oceans Systems TM中（Ocean Networks Canada， 2014a）。

Smart Oceans Systems TM是在NEPTUNE框架下和Oceans2.0的基础上，依托IBM云计算技术架构、大数据技术、机器学习技术、专业数据分析软件和高性能计算等最新的技术，构建的一种新型海洋信息化系统，其逻辑结构如图12-16所示。ONC计划通过Smart Oceans Systems TM建设，能进一步提高加拿大西海岸的海洋环境管理和海洋安全。Smart Oceans Systems TM建设的总体目标包括（Ocean Networks Canada，2014b）：致力于建成一个世界级的海洋安全系统；在加拿大西海岸提供一个世界级的海域管理系统；推动加拿大新的经济增长。

Smart Oceans Systems TM建成之后，将可广泛服务于以下相关领域：

图 12 16 Smart Oceans Systems逻辑结构图（Ocean Networks Canada，2014b）

·海洋交通安全：通过对波浪、海流和水质等海洋环境和航运交通的监测和预警，为海洋交通提供安全保障；

·海洋公共安全：充分利用NEPTUNE和VENUS的资源，实现地震、风暴潮、海底滑坡和海啸等自然灾害的监测、预报和预警，提高加拿大的海洋公共安全；

·海洋环境监管：为海洋环境监管和海洋突发事故提供实时的海洋监测信息，提高海洋环境监管和保护能力。

·辅助决策支持：在NEPTUNE和VENUS资源的支持下，为海洋研究和管理提供科学的辅助决策支持。

5.管理及运行机制

DMAS选择“螺旋模型”软件开发模式进行系统设计和开发（Data Management and Archiving System Team，2006）。“螺旋模型”结合了瀑布模型和快速原型模型，考虑了已有资源和产品规模以及软件项目开发所有的传统阶段，强调了其他模型所忽视的风险分析，特别适合于大型复杂系统。软件测试和集成完全独立于开发过程，由不同部门来实现。集成测试是一个软件测试的阶段，把分开的软件模块组合，作为一个整体进行测试。它在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。当软件通过集成测试时，将被移交给软件部署人员。

在DMAS设计的初始阶段（2006），NEPTUNE组建了专门的研究团队致力于DMAS的开发、设计与管理。当时的DMAS研发团队共有11成员，由NEPTUNE和VENUS共同资助和管理。在这11人的研究团队中，包括2名软件开发工程师、2名UI和Web页面设计师、3名系统管理和开发技术支持人员、1名软件测试与集成工程师和3名项目管理人员。DMAS研发资金主要包括设备费、人员费、差旅费和软件费等几个方面。在将近600万美元的DMAS研究经费预算中（2009年），用于支持研究人员的薪酬的费用高达310多万美元，其比例高于总经费50%（Data Managementand Archiving System Team，2006）。

2007年，加拿大维多利亚大学创立非营利性机构ONC（Ocean Network Canada；Ocean Networks Canada，2014c），专门管理NEPTUNE和VENUS这两个海洋观测系统，包括DMAS。ONC管理和组织架构如图12-17所示。ONC董事会由16名来自加拿大、政府和私营部门的领军人物组成，包括人力资源与管理、财务和审计以及公共事务政策三个委员会，主要职责包括明确关于ONC的所有政策、批准战略和管理计划、监督业务、批准预算、监督绩效以及筹集资金等方面。

图12-17 ONC组织架构图（Ocean Net-works Canada，2014c）

目前，ONC有一个由科学家、工程技术人员和管理人员等组成的85人左右的团队负责NEPTUNE的日常运行和维护工作，按职责服务于ONC下设的观测系统工程部、软件工程部、用户服务部、科学服务部、创新中心、财务及管理中心、事务执行部、对外联络部等部门。其中，负责DMAS研发和运行的相关技术人员有30人左右。