1. Purpose
This Through Life Information Management Plan (TLIMP) represents a common approach of Norway, Denmark, and Sweden to acquire and use information within the frames of the Viking program.
It is intended to be used as basis for:
· Information Management in the Viking Program
· Contract negotiations and discussions with Prime Contractor
· Acquisition of IT systems for the Viking Program.
The Through Life Information Management Strategy /1/ was the first of three reports making up the Information Management study in the Viking program, The Through Life Information Management Plan is the second report. It is based on the Strategy /1/ and the Viking Requirements Document /2/ (Preliminært Kravdokument nr. 2
2. Background
2.1 General Background
2.1.1 Overall project plan with milestones/schedule
The overall plan for the Viking program is:
Study-Concept Phase: 1997-1999
Project Definition Phase: 2000-2002
Design and Production Phase: 2002-2014
Launch of first submarine: 2007
This schedule is based on the requirement of delivery of the first submarine to Denmark in 2007.
2.1.2 How to address cultural changes/training
The participants in the Viking program shall conduct training during the extended Study-Concept Phase in accordance with project plan in order to acquire the necessary skills to use the information systems. Special attention will be given in assuring that the Prime Contractor has necessary qualification and ability to respond in accordance with the Through Life Information Management Plan.
2.1.3 Program Office Staffing.
PG Viking will be supported by a plan coordinator for Systems Engineering, Integration, Quality Assurance, Information Management, and Configuration Management. This person will have the role of Information Manager.
2.1.4 Program participants and location
Prime Contractor (PC) is expected to be a joint venture, IG Viking, consisting of Kockums Naval Systems (KNS), Kongsberg Defense & Aerospace (KDA) and Danyard, (DAA). The joint venture must have financial back-up from their mother companies.
The PC is expected to establish itself at KNS in Malmø, Sweden. KDA have the main organization at Kongsberg, Norway, and DDA in Aalborg, Denmark.
The three nations naval material commands are located in:
· Naval Material Command Norway (Sjøforsvarets Forsyningskommando, SFK): Haakonsvern Naval Base, Bergen, Norway.
· Swedish Defense Material Administration (Forsvarets Materiellverk, FMV): Stockholm, Sweden.
· Naval Material Command Denmark (Søværnets Materielkommando, SMK): Holmen, Copenhagen, Denmark
2.2 Previously defined requirements
The Through Life Information Management Strategy /1/ constitutes the basis of the information requirements for the Viking program. The requirements have been further developed, structured and coordinated with other requirements in the Viking Requirements Document /2/. These information requirements have formed the foundation for this Through Life Information Management Plan:
· All information necessary to design, build, operate and support the Viking submarines should be stored according to a common logical data structure
· The information shall be such that configuration management can be performed during the entire life-cycle.
· The information shall be such that codification can be performed during the entire life-cycle
· The information structure and format shall be developed according to international standards or open de-facto industrial standards.
· Necessary commercial software should be available to support the chosen standards.
· The information should be adaptable to different actors with different needs.
· All information necessary to design, build, operate and support the Viking submarines should be available on-line
· Affected actors in the Viking program should be able to work with the same information simultaneously.
· Both classified and unclassified information shall be available on-line
· Information quality and accuracy through life shall be secured:
· The Viking information system shall not contain any duplication of approved original information.
· The information shall be extensive enough so that adequate traceability can be performed between different data-elements, requirements, functions, and solutions.
· The information should have a logical structure and format so that it does not require reformulation with regard to exchange and sharing.
· A shared data environment and related working processes should be introduced amongst all participating parties, both on the industry side and on the government side.
· The information from the Viking information system shall be exchanged digitally with the national information systems.
· Denmark: The DeMars system
· Norway: Await results of ongoing study and decisions made during the new frigate project
· Sweden: Await results of ongoing study
· Classified and unclassified information shall be handled according to applicable security requirements.
· Unclassified information: A shared data environment based on one logical information structure with integrated access. Data can be allowed to be stored in several geographical places, but in one logical structure.
· Classified Information: Dedicated local systems with approved on-line connection. All classified information shall be managed in the same logical structure as for unclassified information.
· The Viking Through Life Business Model (TLBM) constitutes an agreed description of the Viking lifecycle.
3. Information Requirements (content)
Information requirements should be based on an information analysis. This analysis must be regarded as an integrated part of the proposed study on work processes, methods and tools for the Viking program.
A number of methods are available for information analysis. Two methods have been considered during the development of the Viking Thorough Life Information Management Plan:
· An information analysis based on the Viking TLBM /1/.
· The Information and Information Systems analysis developed by FMV, see Appendix C
An interim information analysis based on the Viking Thorough Life Business Model is described in Appendix B. The aim of this analysis is to identify information objects, and to determine roles and responsibilities for information handling.
It is recommended that also future information analyses for Viking is based on the Viking Thorough Life Business Model, and that these analyses are regarded as living documents that will be subject of further development. They should as a minimum be revised prior to each life-cycle activity according to Figure 4.1.
4. Information Architecture Requirements
The purpose of this Information Architecture is to give a through life common method of linking and referencing information in order to fulfill the Through Life Information Management Strategy /1/. This will facilitate communication and communality across all life-cycle activities and functions
The scope of the Information Architecture is all information necessary to design, build, operate and support the Viking submarines.
The life-cycle of the Viking system is divided into 5 main activities as shown in Figure 4.1 and described in chapter 4.2. The Information Architecture is based on the planning documents of the Product Life-cycle Support (PLCS) initiative /3/. This initiative is intended to develop standards that will be Parts of ISO 10303 (STEP). The shipbuilding Parts of the STEP standard /4/ and the results of PLCS are planned to be the core part of the Viking Architecture. Together these STEP Parts cover three of the five main activities, namely the design, produce and support activities.
The shipbuilding and the life-cycle support Parts of the STEP standard are not ready for use in a major project today. However, they are expected to be ready by the time the Viking programme enters the Design and Production and the Operation Phase respectively, see chapter 2.1.1. Alternatives exists for all three phases, see Chapter 4.2.2.2 and 4.2.3.6.
Within STEP, a project has been started to develop a Part for Systems Engineering. The activity "define user needs and specify requirement" is intended to be covered by this Part of ISO 10303. However, this part will not be ready by the time the Viking programme enters the Project Definition Phase, see chapter 2.1.1. The Viking programme therefore plan to use other standards, see chapter 4.2.1.1 Standards for Systems Engineering.
The activity "operate" is not directly covered by STEP. Information from operations that is required in order to support the Viking submarine is included in PLCS. Other information requirements must be included later, see chapter 4.2.4. Operation.
Figure 4.1 The Viking Information Architecture
The system information is a result of and is linked to the activities that will be carried out, as documented in the Viking Through Life Business Model. In addition to the product information, there is a need for management information like budget, personnel, time etc, This information is not a part of this architecture.
Information needed and how such information is stored, retrieved, and changed depend on the strategies, policies, methods, and processes that will be applicable for the program through the lifetime of the Viking submarine.
4.1 Common Aspects for the Viking Life-cycle Information
A set of common rules and regulations is necessary in order to facilitate communication and traceability of system information between the main activities during the life-cycle. At the very center of this is the concept of product identification.
4.1.1 Product Identification
Defining a "product" is complex because there are many ways of looking at the same thing. STEP defines a product as "a thing or substance produced by natural or artificial processes." Use of the word `produced' in the above definition may communicate the idea that a product is always a physically existing object. This is not true. At the very early stage of its life-cycle, a product may exist simply as a concept described by the customer needs and operational requirements. At the end of the design phase a product may be seen as physically realizable object or "design." It becomes a physically existing object only at the end of the manufacturing process. Once realized the product is to be supported throughout the life-cycle.
To manage products over their life-cycle it is necessary to address these different views of product and to distinguish between the product "As Required," "As Designed," "As Built," and "As Maintained."
4.1.2 Configuration and Structure
Configuration Management shall be applied on all system information covered in this plan.
4.1.3 Linking
Linking regulations will act as enabler to transfer and relate information between life cycle activities and information management systems. The linking layer will contain all necessary transformation protocols and techniques.
4.2 Life Cycle Activities
The life cycle of the Viking system is divided into 5 main activities as shown in Figure 4.1. This brake down is based on information intensive activities, and does not jeopardize the formal project phases. These activities are not necessarily in sequence.
4.2.1 Define User Needs and Specify Requirements
Define User Needs and specify Requirements implies everything from the identification of operational needs to detailed technical requirements. The requirement development will be carried out according to the descriptions and standards as described in the Acquisition Strategy ("Viking Kontraheringsstrategi") document.
The project/product model depicted in Figure 4.2 shows the connections between high-level documents/strategies and specifications down to the basis for production.
Figure 4.2 Viking Strategies and Specifications
4.2.1.1 Standards for Systems Engineering
The Systems Engineering for the Viking program will be based on the IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process (IEEE Std 1220) and the Interim Standard Systems Engineering (EIA/IS 632).
If the system descriptions in the database will not become the basis for a contract or there is a need for distributing specification information by other means, the contents of the database must be documented as requirement specifications. The documentation format will be based on DI-CMAN-80008A for the System/Segment Specification (SSS) and on DI-CMAN-80534 for the System/Segment Design Document (SSDD). They will cover the top-level functional and non-functional requirements, operational scenarios, interfaces, physical structure, and the life cycle processes including the Information Logistics Support (ILS) aspects.
4.2.1.2 The Purpose of the Systems Engineering Standards
The purpose of the DI-CMAN-80008A is:
· Specify the requirements for a system or a segment of a system.
· Provide a general overview of the system or segment that may be used by training personnel, support personnel, or users of the system.
The purpose of the DI-CMAN-80534 is:
· Describe the design of a system/segment and its operational and support environments. It describes the organization of a system or segment as composed of Hardware Configuration Items (HWCI), Computer Software Configuration Items (CSCI), and manual operations.
· Contain the highest-level design information for the system or segment, and it describes the allocation of system requirements to HWCIs, CSCIs, and manual operations.
· To be used by the contractor primarily to present the system design at the System Design Review and use the design information as basis for developing the Software Requirements Specification for each CSCI, the Interface Requirements Specification for the system and the requirements specification for each HWCI.
4.2.2 Design and Production
Based on the previously defined requirements, see Chapter 2.2, the ISO 10303 STEP standard is chosen as the basis for the common logical data structure for design and production in the Viking program.
Several aspects were important:
· The ability of the data structure to hold all necessary information to design and build the Viking submarine.
· The amount of reformulation necessary for design and production information in order to make it suitable for operation and support activities
· Exchange, and sharing of information between the parties involved in design and production
· Integration of information
· Long term storage of information
4.2.2.1 ISO 10303 STEP for Shipbuilding
ISO 10303 STEP is an International Standard for the computer-interpretable representation and exchange of product data. The objective is to provide a mechanism that is capable of describing product data throughout the life cycle of a product, independent from any particular system. The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases and archiving.
At present five Parts or Application Protocols of the Ship Product Model are under development:
1. AP 215 Arrangements
2. AP 216 Molded Forms
3. AP 217 Piping
4. AP 218 Structures
5. AP 226 Mechanical Systems
All of these Application Protocols have reached a stage where they are technically stable.
However, the Ship Product Model is not covering all areas necessary to hold all necessary information for design and production of the Viking submarine. Other solutions must be chosen for Electrical, HVAC, Combat Systems, etc. For some of these areas, like Electrical, Application Protocols developed for other industries can be used. In other areas, like Combat Systems, STEP does not have a solution. A more detailed plan must therefore be developed for the Viking program. This must be done in co-operation with the industry (IG Viking).
STEP translators are available for the major CAD and CAE systems and exchange of information based on STEP Application Protocols is common today. Integration and long-term storage of information based on STEP are less developed. However, several of the major PDM vendors are in the process of developing solutions based on the STEP PDM schema.
4.2.2.2 Alternative Solutions for Design and Production
Two other options for a common logical data structure for the design and production activities have been considered:
1. Standardize on existing, well-proven IT systems. Today, a number of well proven CAD, CAE, and PDM systems exist. On a short term basis, it could be a solution that PG Viking and IG Viking chose the same systems. However, it seems unlikely that PG Viking and the relevant industrial partners in the three countries could agree on using the same systems. Furthermore, the cost of the transfer of the information for operation and support to the three countries will be high.
2. ISO 15926 Oil and Gas. ISO 15926 Oil and Gas will become a standard for integration and sharing of information in the oil and gas industry. The draft standard is already used by the oil and gas industry in Norway, England, and Holland. In addition, USA and Japan have shown interest for this standard. Software to support for the standard exists (Intergraph, IBM, etc.). The standard is not generally accepted in NATO. There is, however, interest shown by defense authorities in some NATO countries (USA, UK), and in Sweden. It is difficult to predict how this standard will be received outside the oil and gas industry.
None of the two alternatives described above are recommended for the Viking program. However, they should be kept in mind if further work shows that it is more difficult than expected to base the common logical data structure on STEP.
4.2.3 Support
Support information implies all information necessary to support the Viking system from the owner's point of view. Traceability must be maintained between support information, design information, and requirement information.
Support information includes the information necessary to support Viking after it is handed over to the owners. The information can be divided into information for four areas:
1. Maintenance
2. Supply chain
3. Configuration management/Change control
4. Support engineering
In addition to the specific information for each of the four areas, there is a set of information that is common. This is called the core information.
4.2.3.1 Information scope for support activities
The information scope for the support activities is:
· Maintenance: Maintain, test, calibrate, repair, and modify the Viking submarine, including schedules, resources, and feedback.
· Supply chain: Buy, store, pack, move, issue and dispose of physical items for the Viking submarine and its support systems.
· Configuration management/Change control: Manage change to a configured item through-out the life cycle, including tracking of serial number where applicable.
· Support engineering: Provide and sustain the support infrastructure.
The information scope is to provide the necessary information for the support activities. The core information is described in chapter 4.1 Common Aspects for the Viking Life Cycle Information
4.2.3.2 Maintenance Information
This section defines and structures the information needed to prevent or respond to predictable failures of the physical product instance (single individual), in a specified usage scenario. This information includes:
· The identification and configuration of the product instance including its physical and functional breakdown.
· The required product performance, to the level needed for maintenance,
· Failure modes and diagnostic characteristics,
· Relevant usage and operating history,
· Maintenance task descriptions and associated resources (parts, tools, skills and facilities),
· A sufficient description of the product to support the maintenance activity (e.g., drawings, video clips etc),
· Test and calibration procedures, following product maintenance,
· Information on the return or safe disposal of items no longer required.
Note: Most of this data is generated by the Design and Support Engineering processes.
4.2.3.3 Supply Chain Information
Operational availability cannot be sustained without access to appropriate spare parts. This section defines the part related information that is relevant to maintenance of the physical product. This includes:
· The identification and properties of parts, including packaging, handling storage and transportation characteristics,
· The information needed to procure parts, including details of alternative suppliers.
· The planned location of spares holdings.
4.2.3.4 CM/Change control
Changes to the product configuration may change the maintenance and spares required. Implementation of a change may be a maintenance task. This section addresses the information needed to manage changes to the configuration of an existing product.
In addition, because of the high importance of the configuration structure to product information management, this section also address the information needed to develop a configuration structure as part of the design activity and to manage changes to design. It does not address the re-engineering of the design solution.
4.2.3.5 Support Engineering
This section defines the information needed to develop and to optimize the support solution for the product, initially and during life. The information needed to achieve this includes:
· Intended operating and maintenance scenarios.
· Supportability characteristics (required, forecast and actual).
· Classification of maintainer skills.
· Policies and procedures for maintenance and supply.
· Intended support solutions (the required maintenance and supply activities).
· The reasons for choosing support solutions (e.g., Level of Repair Analysis).
4.2.3.6 Alternative Solutions for Support
ISO 10303 - STEP. STEP is the recommended standards for a logical data structure for support as well as for design and production. Support is not yet covered by STEP. NATO CALS has, however, taken an initiative to have this area covered (Product Life Cycle Support - PLCS), and there exist plans for a project that will develop such a standard during the period 1999-2001.
STEP is supported by several of the large software vendors, and a large number of software systems supporting this standard already exist. Most likely, this will also be the case for a prospective PLCS standard. It is expected that STEP will be generally accepted in NATO when it has reached a further level of maturity.
Several other options exists for a logical data structure for support:
· Standardize on existing, well-proven IT systems. Today, there exist several well-proven systems in this category, for instance SAP. On a short term basis, this may be the best solution. However, it seems unlikely that all three Defense procurement agencies and relevant industrial partners in the three countries all agree on purchasing the same systems. Furthermore, the cost of a potential transfer to different systems in the future will be large. This alternative must however be seriously considered. If STEP or one of the marked leading systems is chosen, it will have (or the vendor will develop) external communication protocols that are compatible with other systems. If one of the standards listed below turns out to be generally accepted, communication solutions based on these standards will most likely be developed.
· UK Def. Std. 0060 This standard has been chosen as interim standard for Integrated Logistic Support (ILS) in Norway. It is based on well-proven technology and there exists software to support it. It is however partially based on old technology, and it is a combination of three standards (U.S. MIL STD 1388, AECMA 2000M and AECMA 1000D). This results in the same data being stored more than once. The standard is not generally accepted by NATO. Nevertheless, for ILS solutions based on accepted standards, it seems like the lowest risk solution.
· NATO CALS Data Model. This specification is developed by NATO CALS. It contains several good elements, but is still not complete. It is not generally accepted in NATO, and there is limited software to support it. However, software is under development and a further development of the NATO CALS Data Model could be an alternative for the Viking program.
None of the three alternatives described above are recommended for the Viking program. However, they should be kept in mind if further work shows that it is more difficult than expected to base the common logical data structure on STEP.
4.2.4 Operation
This implies information necessary to conduct Operational Logistics, including co-operative logistics with other elements and weapon systems.
4.2.4.1 Operational Information Requirements
The Viking Information Management System should provide necessary information to the Operational support activity during operational missions. Information elements according to Logistical messages in the ADatP-3 (Allied Data Publication nr 3) will define the detailed information requirements. This has to be taken into account when finalizing the support phase information system.
No further detailed requirements will be determined at this point in time, due to significant development in the Operational Command and Control area concerning information requirements and handling.
5. Hardware requirements inclusive basis SW.
At present, no specific requirements have been identified. Hardware requirements will be determined at contract point according to functional performance requirements.
6. SoftWare Applications Requirements
Which software applications will be use for each information group throughout the lifecycle activities.
Define user needs and specify requirements
Design/Construction
Support/Operation
· Microsoft Systems Engineering software
· Open PDM systems
· Open PDM systems
· CAD, CAE and other design systems
· Open PDM, etc. and/or national support systems
· IETM and CBT systems
7. Roles and Responsibilities
This chapter determine all roles and responsibilities for information creators, information managers, information owner and users throughout the lifecycle:
· Information Creators: Persons or organizations that creates information and deliver it to the Viking Information Management System.
· Information manager: The person responsible for the Information Architecture and the Information Management System. "The Structure and System owner" This role is also responsible for the legal aspects for information as described in Appendix E.
· Information Owner: The person or organization responsible for the information content.
· Information user: Persons or organization that uses information stored in the Viking Information Management System
.
8. RELEVANT DATA SOURCES
8.1 External Information Environment
At present, a large number of legacy systems are in use in Sweden, Denmark, and Norway. Some of these systems are old and will be replaced before year 2000. Some are new and a long life is expected.
8.1.1 The military services
Within the military services the situation is different in the three countries:
· Denmark has made a decision to replace all the old systems with one integrated system (DeMars) common to the entire Danish Defense. This system will be implemented in the period 1999-2004 and will therefore be in full operation well before the first Viking submarine will be delivered. This means that for the Danish navy, only the DeMars system needs to be addressed.
· Sweden is using a number of legacy systems, see reference /5/. The Swedish Defense has decided to put all software system development on hold until an ongoing study on the issue has been completed. This study is planned to be completed within a couple of years and until then it is difficult to make assumptions with respect to relevant IT trends, policies and plans.
· Norway is also using a number of legacy systems, see reference /6/. The Norwegian Defense is at present carrying out several studies and projects on information management and information systems. These activities are planned to be completed within a couple of years, and until then, it is difficult to make assumptions with respect to relevant IT trends, policies and plans.
8.1.2 Defense industries in Sweden, Denmark and Norway
For defense industries in Sweden, Denmark and Norway some information has been received on status and near tem plans for IT systems. Very little information is available on plans for information management. This must be addressed at a later stage in co-operation between PG Viking and the relevant industry.
9.0 Implementation Plan
This chapter is mainly focused on the near future, and will act as preparation for the next program phase.
9.1 Infrastructure Implementation Plan
The following activities will be carried out:
· Discussion with potential information management system suppliers in order to determine which system to use to specify requirements, analyze, and organize user needs.
· Determine how to install and run the Viking Information Management System
· All responsibility with Prime Contractor
· Separation between Prime Contractor and PG Viking with split responsibility
· Third party support
· Determine the necessary level of support from the supplier of the Viking Information Management System
· Implementation of agreed system, including necessary hardware
· Training and testing
· Mapping of existing Objectives, User Needs, and Requirements into the Viking Information Management System.
9.2 Contract Strategy for Information and Infrastructure
Discussion with IG Viking, the Prime Contractor, concerning detailed roles and relationships for the coming phase will be initiated and document in the contract for the coming phase. The aim shall be to have full transparency of all information from the Prime Contractor, without any delay.
10. Review plan for the IMP
This Plan shall be revisited when necessary, and must be regarded as a living document. As a minimum, it shall be renewed at each new lifecycle phase.
Next Renewal no later than: Prior to development Contract
11. References
/1/
Through Life Information Management Strategy, PG Viking, 1998
/2/
Viking Requirements Document (Preliminært Kravdokument nr. 2), PG Viking, 1998
/3/
http://www.cals.nato.be
/4/
http://www.nist.gov/sc4
/5/
List of Swedish legacy systems, FMV, 1998.
/6/
List of Norwegian legacy systems, SFK, 1998.
Please do not delete the Bookmark named "numPages" on this last page in the report.
- o0o -
|
