20100217 sopes overview for v3
•
0 recomendaciones•798 vistas
Back grounder on the OMG Shared Operational Picture Exchange Services Standardization and the JC3IEDM.
![Topics for the Presentation ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
Similar a 20100217 sopes overview for v3
Similar a 20100217 sopes overview for v3 (20)
Último
Último (20)
20100217 sopes overview for v3
- 1. OMG/SOPES – Information Interoperability Strategy February 2010 Presented by: Mike Abramson President, Advanced Systems Management Group Co-chair OMG C4I Domain Task Force
- 4. Interoperability (ATCCIS/MIP) JC3IEDM Data Exchange Mechanism Message Exchange Mechanism Other Government Departments (OGDs) Other Levels of Government Non-Government Organizations (NGOs) Non-MIP Nations Non-MIP CoIs Private Volunteer Organizations (PVOs) Reach back to National Domain Staging information from one operational Domain to another in a secure and trusted Manner was considered and National Issue
- 8. Information Interoperability (circa 2003) Organization ≈ Capability ≈ System ≈ Service Multiple Peer-to-Peer Gateways
- 11. Elements of and Information Exchange Specification (Circa 2004) MIP JC3IEDM OMG SOPES IEDM MIP PDU, XSD NIEM XSDs C2 Core / UCore XSD CAP CP XSD OMG SOPES XSDs Examples Domain Artifacts Rearranging the Stovepipes Not Directly Supported by Architecture Frameworks
- 12. SOPES Conceptual Architecture (Design to Audit; circa 2003 ) Information Exchange Model: - Aggregation Rules - Marshalling Rules - Transformations - Dynamic and Fixed Filters - Semantic Guards Generation of Executable Rules Executable Version of Operational Information Exchange Rules Runtime Control over Information Sharing: - COI Configuration - Information Release Control - Policy/Rule Assignment - Policy Activation / Deactivation Policy / Rule Enforcement Services / Trusted Data Service Application Programme Interface (API) to the Data Service Storage of Architecture Models User Developed Operational Applications DEMONSTRATIONS: 2000 :MIP, 2002/03: BOWMAN CIP User Selected Infrastructure User Selected Infrastructure User Selected Infrastructure 2006: OMG User Developed Analysis Tools
- 15. SOPES: Aligned To Architecture Constructs (2009) SOPES AF VIEWS SOPES AF VIEWS SOPES AF VIEWS
- 35. Demo Contract Topology PSC MOC NDHQ RCMP PublicSafety_SA Maritime_Alert Police_SA Police_SA Maritime_COP Maritime_COP Manual Activation
- 36. Pedigree of the OMG Interoperability Direction Interoperability by Common Products Interoperability by Common Data Schema & Middleware Specs Interoperability by Common Data Schema & Middleware Specs Interoperability by Shared Exchange Policies and Semantics
- 39. Worldwide Scope Adaptive Adobe Alcatel/Lucent ASMG AT&T BAE Systems BEA Systems Boeing Borland CA Cisco Credit Suisse Daimler-Chrysler Deere & Co. DND DOD EDS Fujitsu General Dynamics HP Hitachi IBM IDS Scheer IONA Interactive Objects Kaiser-Permanente Kennedy Carter Lockheed Martin Mentor Graphics Motorola SAP Siemens Sun Telefonica Thales Toshiba Unisys VHA Walt Disney NASA NIST Nokia Northrop Oracle Promia PrismTech Raytheon Rockwell
- 40. Recent Efforts at OMG Architecture Board Intellectual Property Policy Subcommittee Object and Reference Model AB Subcommittee Specification Management AB Subcommittee Architecture Ecosystem ABSIG MDA Users ABSIG Process Metamodel ABSIG Service Oriented Architecture ABSIG Sustainability AB SIG Domain Technology Committee : Business Modeling and Integration DTF Consultation, Command, Control, Communications & Intelligence (C4I) DTF Emergency, Crisis and Major Event Management Domain Special Interest Group (ECMEM DSIG) Finance DTF Government DTF Healthcare DTF Life Sciences Research DTF Manufacturing Technology and Industrial Systems DTF Robotics DTF Software-Based Communications DTF Space DTF Mathematical Formalism SIG Regulatory Compliance DSIG Super Distributed Objects DSIG Systems Engineering DSIG Platform Technology Committee : Analysis and Design PTF Architecture-Driven Modernization PTF Middleware and Related Services PTF [email_address] System Assurance PTF Agent PSIG Data Distribution Services PSIG Japan PSIG Korea PSIG Ontology PSIG Telecommunications PSIG Abstract Syntax Tree Metamodel (ASTM) FTF Ada Language Mapping 1.3 RTF ADM Knowledge Discovery Metamodel (KDM) 1.2 RTF 2nd CWM 1.2 RTF DDS Interoperability 2.1 RTF 3 rd Data Distribution Service RTF MOF 2 Core RTF MOF Model to Text 1.1 RTF MOF QVT 1.1 RTF OCL 2.1 RTF Ontology Definition Metamodel (ODM) 1.1 RTF UML 2.3 RTF UML Profile for Systems Engineering (SysML) 1.2 RTF UML Profile for Voice 1.1 RTF XMI for MOF 2 (XMI 2.1) RTF UPDM RTF
- 41. Strategic and Liaison Relationships
- 48. SOPES Target
- 49. SOPES Goals
Notas del editor
- MIP and ATCCIS provided a pristine environment in which partnering agencies can replicate data between operational nodes using a standardized interface (Data Exchange Mechanism [DEM]). Ongoing challenges: The advent of SOA, WEB Services and DDS have surpassed the capabilities of the DEM and many agencies want to adopt these technologies through COTS implementations The current implementation do not provide adequate support for Information protection and security The current implementation do not provide adequate support for dynamic CoI setup and teardown Addressing virtualized cross domain solutions Addressing data aggregation, transformation and marshalling challenges Addressing the need of National requirements to stage information into operational domain and he MIP environment is not in the mandate of the MIP community Addressing the need to develop information artifacts that enable TRA and C&A processes so implementations can be certified Addressing the need to support interagency (OGDs, PVOs, NGOs, Non-MIP Nations, … other levels of government) Addressing the need to support operations other than military Addressing the challenges with the military perspective JC3IEDM is a great start – but not the end of the story. The Emergency, Crisis and Major Event communities need to be supported such that they can adopted the JC3IEDM. For this we need to promote the development of COTS products and Open-source applications that integrate the JC3IEDM. We need to support organizations that do not have the development budget and resources of the Military We also need to remove the military and Army stigma of the JC3IEDM.
- Long dedicated effort of the OMG and the US delegation to MIP. IEF is handicapped by the lack of targeted resources and a focussed set of requirements from the user community.
- Long dedicated effort of the OMG and the US delegation to MIP. IEF is handicapped by the lack of targeted resources and a focussed set of requirements from the user community.
- Information Interoperability comprises functions, services and technologies: That enable the exchange of meaningful information within and between organizations (heterogeneous Information Systems) in a manner that aid decision makers That improve the quality of shared information: Accuracy: semantics to accurately convey the perceived situation. Relevance: information tailored to specific requirements of the mission, role, task or situation at hand. Timeliness: information flow required to support key processes, including decision making. Usability: information presented in a common, easily understood format. Completeness: information that provides all necessary (or available) information needed to make decisions. Brevity: information tailored to the level-of-detail required to make decisions and reduces data overload. Trustworthiness: information quality and content can be trusted by stakeholders, decision makers and users. Protected: Information is protected from inadvertent or Malicious Release That enforce information sharing policy: Need to share Need to Protect (Sensitivity, classification, privacy, etc …) Provide auditability back to enterprise and community information architectures Document business rules governing the aggregation, marshalling, filtering, guarding, Implement community standards
- Seeking an AF and technology agnostic process for defining information exchange agreements and communities of interest. Challenges: The need to architect information exchange agreements is foreign to the IM community (see TOGAF, DODAF, MODAF, Zachman, …) Community focus on the XML and XSDs as the basis for interoperability (another partial solution brittle, rigid and costly) – no different than ADATP-3, OTHgold, USMTF, … The separation of information protection and information security issues is foreign to the IM community Little or not support for information sensitivity, privacy and classification issues Little or no support for data aggregation challenges Little community understanding of the IM and AF issues related to interoperability
- SOPES started with some basic Architectural concepts that were used to identify key areas of standardization. Data patterns and Architectural Views for specifying the patterns (core concepts to be integrated into UPDM 2.0 and DODAF 2.x) ASMG identified the shortfalls (information staging and information protection) in interoperability strategies security as early as 1999 Papers written for DND ATCCIS and MIP Re-issued for FELEX and EISE Approach demonstrated in 2000, 2003 (BOWMAN) and 2006 ASMG spearheaded these efforts for the at OMG, MIP (through the US DOD [OSD NII COI and Architecture]) and DOD ASMG is the prime contributor to these efforts Policy Model for the Operational Environment (Pending) Information Exchange Mechanism (Pending) Security Policy Domain Model (Pending) Security Views for Architecture (Pending) Tagging and Labelling Domain Model (Pending) Audit Services (Pending) Scenario Analysis Services / M&S Services (Pending) C&A, TRA and SOS Domain Model (Pending) C&A, TRA and SOS Services (Pending) Other Demonstrations and adoptions: 2000 Demonstration as Canadian Prototype to MIP based on model generated exchange policies 2002 Risk mitigation prototype developed for GD UK BOWMAN CIP – underpinning of BOWMAN Information Architecture 2006 Dynamically modifiable information exchange policies demonstrated at OMG 2007-2010 Modeling paradigm used for SOPES IEDM Specification 2009 Modeling paradigm adopted by UPDM – and DODAF 2 groups
- We spent a lot of time and effort back filling missing capability: Information Views in architecture Information Protection Views in Architecture Concepts for semantics and data patterns Alignment between information models and data models other
- We required a process
- 1. Provide an inventory of current emergency management M&S, GIS and other data dissemination solutions, and the technologies deployed. This represents the “as-is” or status quo cluster-wide information exchange situation currently in place in the EM system. 2. Summarize via GAP analysis the EM cluster members’ technology infrastructure requirements, and information exchange / data dissemination needs, goals and objectives. 3. Identify all pertinent information required to aid in the design of a new (ideal) information exchange / data dissemination system matching the needs, goals and requirements of the EM cluster. 4. Draft a move forwards position – a road map – demonstrating conformance to an Open standards, web-based and GIS-enabled secure emergency management / incidence response System of Systems. 5. Write a “Charter” for the Mandate for EM Interoperability / information exchange offerings, and; frame the Specification for an Emergency Management Common Interest Group (EM CIG) Charter Document, and solicit OMG’s support as the requisite standards body, to ensure there is a standards setting vehicle in place for enabling the vision and roadmap identified by EM stakeholders.
- 1. Provide an inventory of current emergency management M&S, GIS and other data dissemination solutions, and the technologies deployed. This represents the “as-is” or status quo cluster-wide information exchange situation currently in place in the EM system. 2. Summarize via GAP analysis the EM cluster members’ technology infrastructure requirements, and information exchange / data dissemination needs, goals and objectives. 3. Identify all pertinent information required to aid in the design of a new (ideal) information exchange / data dissemination system matching the needs, goals and requirements of the EM cluster. 4. Draft a move forwards position – a road map – demonstrating conformance to an Open standards, web-based and GIS-enabled secure emergency management / incidence response System of Systems. 5. Write a “Charter” for the Mandate for EM Interoperability / information exchange offerings, and; frame the Specification for an Emergency Management Common Interest Group (EM CIG) Charter Document, and solicit OMG’s support as the requisite standards body, to ensure there is a standards setting vehicle in place for enabling the vision and roadmap identified by EM stakeholders.
- International non-for-profit the develops open specifications for information system interoperability that are Reusable, interoperable and portable – focus on: Interoperable Metadata management. These standards are requested, submitted, adopted and maintained by the membership.
- World Wide Consortium of over 500 members form industry, Academia and Government.
- WE MAINTAIN RELATIONSHIPS WITH MANY OTHER STANDARDS BODYS.
- WE MAINTAIN RELATIONSHIPS WITH MANY OTHER STANDARDS BODYS.
- Recent Activities: Naval Combat Management Systems Alert Management Application Management SOPES: Information Exchange Data Model (Data Patterns for JC3IEDM 3.1c) UPDM version 1.0 (Version 2.0 RFP on the street.
- Software Driven Applications Traditional Software development based on full defined specifications Rigid/Brittle Solutions Typically built of per-to-peer interfaces High Maintenance Costs Required detailed understanding of operational requirements (traditional top down) Not conducive to dynamic real-world environments Poor retention of corporate knowledge Model Driven Architecture Model Driven Specifications driving Code Generation Same as above Code generation can be as low a 20% for algorithm intensive environments Policy Driven Services Development of exchange policies that are enforced by middleware Improvement of code based solutions Typically hand coded Typically targeting unclassified data exchange (not semantic interoperability) Typically short initial benefits – difficult to maintain Poor retention of corporate knowledge Architecture Driven Policy Services Use architecture models to generate policies that enforced by middleware, requires New – few products New – Architecture concepts New ways of approaching development But has real-world exemplars – ERD SQL/DDL Database applications