Home
[IEEE 2007 IEEE Electric Ship Technologies Symposium - Arlington, VA, USA (2007.05.21-2007.05.23)] 2007 IEEE Electric Ship Technologies Symposium - ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems
[IEEE 2007 IEEE Electric Ship Technologies Symposium - Arlington, VA, USA (2007.05.21-2007.05.23)] 2007 IEEE Electric Ship Technologies Symposium - ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems
May 8, 2018 | Author: Anonymous |
Category:
Documents
Description
ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems Author: Mike Roa, American Bureau of Shipping Abstract: The following paper provides a rationale, background, and summary of how modern Information Technology is being used effectively by the U.S. Navy in mission critical applications for shipboard control, navigation, and interior communication systems. The paper provides a background and summary of the updated American Bureau of Shipping (ABS) Naval Vessel Rules (NVR)1 requirements for Mission Critical Networks, Software Development, and Safety Critical Control Systems. The Naval Sea Systems Command (NAVSEA) and the American Bureau of Shipping (ABS) have partnered to co-write these rules which were initially drafted by comparing the existing commercial Steel Vessel Rules (SVR)2 in these areas with current United States Navy shipbuilding practice from recent shipbuilding programs. The requirements for Safety Critical Systems were then derived from the Safety of Flight (SoF) criteria for U.S. Navy submarine ship control systems. The paper explains the relationship between the Naval Technical Authority and the American Bureau of Shipping and their respective roles in the certification of control, automation, and navigation systems software and networks. The current requirements prescribed in the Naval Vessel Rules are compared and contrasted with the commercial Steel Vessel Rules and the merits and rationale behind each approach are discussed. Background: Due to recent rapid developments and advancements in information technology, the U.S. Navy has been developing and maintaining updated requirements that address the unique aspects of highly advanced state-of-the-art shipwide computer networks that provide integrated control and monitoring of numerous mission-critical systems such as machinery control and navigation systems. Secondly, the Navy has had to develop rigorous software and system development criteria due to the high level of integration required and the complexity of modern naval control and navigation systems. Lastly, the advent of âfly-by-wireâ computer based systems for the purposes of providing safety critical ship control functions has resulted in the Surface community adopting extremely 1 ABS Guide for Building and Classing Naval Vessels (2004) 2 ABS Rules for Building and Classing Steel Vessels (2006) stringent criteria from the Submarine community for certification of Safety Critical controls systems software and hardware. Concurrently, rapid advances in commercial marine industry have outpaced legacy requirements that were in place for naval vessels in the U.S. Navy General Specifications for Shipbuilding (GENSPECs)3 as was the case in many areas of Hull, Mechanical, and Electrical ship design. The Navy saw the need to draft new requirements for networks, software development, and safety critical systems in order to keep up with modern technologies and leverage technologies being applied in commercial applications. Through collaboration with the ship classification society American Bureau of Shipping (ABS), it was realized that adopting some elements of the commercial approach to ship classification would allow the Navy to take advantage of the rapid advancing technologies being used in commercial industry. However, the ABS commercial Steel Vessel Rules used on merchant vessels were not considered appropriate for a military warship which has to meet unique military requirements such as survivability, electromagnetic compatibility, and signatures. This was the case in many areas of ship design, not just control and navigation systems. Accordingly, the need to replace legacy requirements and overhaul the procurement process led the U.S. Navy to collaborate with ABS on development of a new set of rules that would be written specifically for Naval Vessels. Drafting the rules in the area of control and navigation systems turned out to be one of the most challenging areas for ABS and the Navy due to the vast differences in the military and commercial design approaches for control and navigation systems. Also complicating matters is the Navyâs need to interface these systems with military systems such as combat systems, weapons systems, exterior communication systems, and military sensors that are outside the scope of Hull, Mechanical, and Electrical (H,M, & E) systems and are not covered by the Naval Vessel Rules. Specifically, the Steel Vessel Rules did not come close to 3 U.S. Navy General Specifications for Shipbuilding, 1995 1381-4244-0947-0/07 $25.00 © 2007 IEEE. ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems Author: Mike Roa, American Bureau of Shipping addressing the needs of what the Navy would require in terms of the following three key areas: - Mission Critical Networks - Software Development Processes - Safety Critical Systems These three topic areas have been recently overhauled in the last edition of the NVR and application of the rules in these areas continues to be a challenge as ABS develops further infrastructure and expertise in these key technologies. The paper identifies specific areas of the rules that require further development and improvement and provides suggestions how the ship classification and rule-making processes can be improved. Rationale for the Application of Modern Information Technology on Naval Ships: The application of Internet Protocol (TCP/IP) based network technology to Navy control, navigation, and interior communications systems offers possibilities for highly integrated control and monitoring systems as well as fully integrated communications services including voice, data, and video while maintaining interoperability with legacy communication systems. The need for updated network technology can be understood by considering the level of integration being achieved in contemporary shipboard backbone networks. Modern Naval Total Ship Computing Environment (TSCE) networks have been combined such that control signals, navigation signals, and interior communications (voice, data, video) are all transported across a common network that employs technologies such as Asynchronous Transfer Mode (ATM) using Internet Protocol (TCP/IP) and application programming interfaces. In the past, each control, navigation, or IC system was a stand alone system that used legacy based analog technology. As digital technology began to replace legacy systems, stand alone networks employing a variety of technologies, topologies, and protocols where employed. As industry standards were developed, such as CANBUS and PROFIBUS, DeviceNet, there was a tendency for various system developers to select design their niche networks with whatever protocols worked best for their specific applications. Interfacing these multiple conflicting types of protocols became a huge task and was a drain of resources. Upgrading systems presented an even greater challenge as the Navy was forced to deal with multiple vendors using proprietary software and network technologies. With the advent of Internet Protocols and Open Architecture (OA) Standards, the Navy realized the great potential for improved system integration and using network technology to minimize the amount of redundant cable for various systems. This new approach to Networks became known in the late 1990s as the âNetwork Centricâ design. The common network is referred to as the âTotal Ship Computing Environmentâ or TSCE. âTSCEiâ is an integrated suite of standardized OA hardware, operating system, middleware and infrastructure services. It forms the backbone of the Total Ship Computing Environment (TSCE). The TSCE is a robust, enterprise-network computing system on which all future Naval ship control, navigation, and interior communication systems application software programs run. Development of Naval Vessel Rules: Accordingly, the American Bureau of Shipping (ABS) proceeded with development of Naval Vessel Rules as a joint effort with the Naval Sea Systems Command (NAVSEA). NAVSEA and ABS jointly developed and implemented a set of Naval Vessel Rules to be used in the design, construction, maintenance and modernization of non-nuclear naval combatant ships. After many years of success in applying the ABS ship classification process on many Sealift and Naval Auxiliary programs the Navy and ABS decided to collaborate to address the lower risk aspects of designing and certifying non-nuclear naval combatant ships. This allows in-house Navy engineering resources to be focused more on the higher risk mission related aspects of combatants, while maintaining technical control via close collaboration with ABS on the Naval Vessel Rules - the foundation for the process. The Navy retains technical authority, but uses ABS as a business partner to administer the Naval Vessel Rules, and as an agent in classing ships to the Naval Vessel Rules. The ABS Naval Vessel Rules, as tailored by approved exceptions, are currently 139 ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems Author: Mike Roa, American Bureau of Shipping applicable for the USS FREEDOM (LCS-1), USS INDEPENDENCE (LCS-2), and USS ZUMMWALT (DDG-1000) shipbuilding programs and will be applicable for all future non-nuclear surface combatants. As per the rules, the Naval Technical Authority remains in the lead role for certification of Control and Navigation Systems Software, Mission Critical Networks, and Safety Critical Control Systems. The following is a summary of the topics covered by the NVR 2004 Rules in these key areas: NVR Section 4-1-13, Network Architecture and Cabling: Origin: Derived from NSWC Philadelphia Network Design Requirements Document Applicability: limited to control, automation, and navigation system networks. Network system requirements: security, non- volatile memory, recovery from power failure, monitoring, response time, fail-safe, disaster recovery Network topology requirements: mesh topology, connection of switches Network cabling and Fiber Optic Cable Plant requirements: mil-specs invoked Government Network Design Standard - invoked by reference, this document is issued by NSWC Philadelphia and contains further detailed requirements for network performance and equipment NVR Section 4-1-12, Software and Hardware: Origin: Derived from recent ship specifications for recent shipbuilding programs Certification Process: Provides requirements for development and certification of software for control and navigation systems. Process is meant to be tailored for each specific vessel design. Scope of Applicability: Only applicable for new software that is being developed or for changes to COTS software. CMMI Level 3: Software Developer organization must be independently appraised to Capability Maturity Model Integration (CMMI) Level 3 or higher. Software System Safety Program: must meet System Safety requirements in accordance with MIL-STD-8824 or IEC 615085. Independent Validation and Verification (IV&V): Software must be verified and validated by an independent third party in accordance with IEEE Std. 1012a6 and IEEE 122077. Verification and Validation: NSWC Philadelphia: For U.S. Navy vessels, software shall be verified and validated as directed by Naval Surface Warfare Center Philadelphia or as otherwise directed by the Naval Technical Authority. Information Assurance: systems are to employ physical, personnel, and procedural security features to provide protection adequate to handle, control, process, and store information utilizing the Department of Defense (DOD) Information Technology Security Certification and Accreditation Process (DITSCAP), DOD 5200.40.8 Software Source Code Rights: Core Control systems software source code shall be provided to the Naval Technical Authority or to a third party escrow company. The Naval Technical Authority shall approve any escrow company. NVR Section 4-1-12/5, Safety Critical Systems: Origin: Derived from the Safety of Flight (SoF) criteria for U.S. Navy submarine ship control systems. U.S. Navy âFly-by-wireâ type requirements: adopted from Submarine standards and tailored to apply to surface combatant vessels. 4 MIL-STD-882, SYSTEM SAFETY, 10-FEB-2000 5 IEC Pub. 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems, Edition 1.0, (2005-01) 6 IEEE Std. 1012a, Standard for Software Verification and Validation, 2004 7 IEC 12207, Standard for Information Technologyâ Software life cycle processes âDescription, 1996 8 Department of Defense (DOD) Information Technology Security Certification and Accreditation Process (DITSCAP), DOD 5200.40 140 ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems Author: Mike Roa, American Bureau of Shipping Un-safe conditions: This section requires Naval Technical Authority to develop an âun-safe conditionsâ list for the vessel with concurrence from Naval Administration. This may include conditions such as grounding, sinking, collision, uncontrolled flooding, catastrophic pollution, uncontrolled fire, etc. Hazard analysis: is performed by System Developer to identify which systems and/or equipment may cause and un-safe condition as a result of a failure. âSafety criticalâ control systems: Any systems or equipment required to prevent the âun-safe conditionsâ are designated as âSafety Criticalâ and are required to meet additional more stringent requirements for software development, certification, and testing. This additional criterion is above and beyond the baseline requirements. Additional Safety Criteria: more stringent requirements for software development applies, safety analysis requirements, system safety requirements, interface management, and software unit and system level testing, dockside testing, and At-Sea/Sea Trials testing. Comparison between Steel Vessel Rules (SVR) and Naval Vessel Rules (NVR): One of the biggest challenges in drafting the NVR was to capture all of the state of the art requirements to reflect the latest available technology. The introduction of modern Information Technologies (IT) into the shipboard environment has become the new framework for ship control and navigation systems. The operational requirements and mission criticality of these enabling technologies requires a specialized network design differing from the standard information handling characteristics of a typical IT network. These systems are being designed as fully meshed, redundant, fault tolerant networks with specialized fail-over requirements as the primary goals. Implementation of these technologies has improved numerous aspects of control and navigation systems including fault tolerance, redundancy, survivability, data accuracy, response time, level of integration, level of automation, information logging, data acquisition, condition based maintenance, reduced crew workload and improved quality of life for shipboard personnel. The U.S. Navy has even explored allowing unattended operation of machinery spaces as is routinely done in the commercial world. The major driver in the development and introduction of computer based technology has been the need to meet mission requirements safely with minimum manning. Safety critical systems such as ship control, damage control, and automated navigation have required the U.S. Navy to establish very high certification standards for safety critical system software and hardware. The transmission of safety critical information in a digital format over integrated computer networks is considerably different from the legacy dedicated hardwired analog electrical or electro-mechanical systems of the past. Programmable Logic Controllers have replaced electro-mechanical relays of the past placing an even greater reliance on software based control algorithms, data accuracy, latency, and data transmission rates. As the effort to draft NVR network and software requirements commenced it was quickly realized that the commercial rules were completely insufficient with respect to the level of detail and robustness required for a control system employed on U.S. Navy surface combatants. The commercial Steel Vessel Rules and focus on a review of the overall system architecture and details of the hardware. A limited amount of criteria for software logic charts and functional descriptions is required to be submitted as well as evidence that the system software has been developed in accordance with a recognized quality standard (like ISO 9001). In the commercial world, verification and validation of the software is something that gets accomplished during a limited Factory Acceptance Tests (to demonstrate proper basic operation), followed by full system demonstration during sea trials. There are also less things that need to be submitted for review and approval; in terms of networks and software, the commercial rules do not require as much information to be reviewed and approved. The Navy approach requires a more detailed review of the software documentation, additional safety analyses, and a more rigorous testing program. The Naval Technical Authority 141 ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems Author: Mike Roa, American Bureau of Shipping reviews in detail the software documentation relating to the development processes, software testing program, and the proposed Independent Verification and Validation methodology. In addition, further detailed analyses (such as system safety analyses) are required based on the ship platform. Additional test documents and test procedures may be required which are tailored for ship platform specific characteristics such as stress testing to demonstrate software and network systems can function properly under worst case data loading after a failure has occurred. Other unique test programs are developed as required. The main reasons for these differences between commercial and naval requirements in the area of networks and software are: - higher level of complexity of naval control systems - the need for the capability of distributed control workstations which requires more interfaces and more integration - a higher level of survivability required for naval systems which includes things like full mesh networks - higher level of integration with other shipboard computer based systems - greater need for life cycle documentation and records to be maintained and kept since the Navy is more likely to upgrade or modify systems In terms of what the Navy is looking for with respect to networks, their objectives for designing a network for control and automation systems and navigation systems are as follows: - Outline the building blocks of a generic shipboard cable plant topology design for both backbone and local user connections. - Provide installation and design guidance, including survivability, redundancy, sparing, growth, high bandwidth capacity, high availability, low Mean Time To Repair (MTTR), and performance. - Ensure shipboard environmental and damage control tolerance for shipboard cable plant and network hardware, so the infrastructure and user systems will operate reliably under the most adverse operating condition. - Outline the building blocks of a survivable, fault tolerant network infrastructure associated with the integrated system communication links, communication media, topology architecture, Local Area Network standards, and the data management methods that provide an integral process. - Reduce crew workload and improve quality of life, enhance readiness, and decrease operation and support (O&S) cost The differences between commercial rules and naval rules are summarized in the following table: Table 1 - NVR vs SVR Comparison Table Topic SVR NVR Scope Only covers Propulsion Remote Control and Machinery Automation Systems and Steering Controls â very narrow in scope. Other systems are outside of the scope of ABS classification. Navigation systems are covered by NIBS Notation which is optional. The only IC systems are those required for propulsion and steering. Covers all major machinery, navigation, and interior communication systems. Rules are all encompassing. Plans and data to be submitted Limited list of basic plans and data as required to verify the Rules Requires exhaustive documentation for software development and safety critical systems; even further data is required Survivability Notation SOANS. Software certification Only requires Software logic flow chart, description of software functions, self-test features, response time in respect of design data volume and CPU capability, data communication protocol (for integrated systems), documentation on quality standard of software development and testing. Many additional requirements including CMMI Level 3 appraisal, Software System Safety Program, I V&V per IEEE Std 1012a and IEC 12207, Information Assurance (DITSCAP), Software Source Code Rights, Information item Matrix per IEEE 12207. 142 ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems Author: Mike Roa, American Bureau of Shipping Topic SVR NVR Safety Critical Systems No special requirements Un-safe conditions list, hazard analysis, Requirements Verification Traceability Matrix, Safety Analysis requirements, System safety requirements, interface management, and software unit and system level testing, dockside testing, and At-Sea/Sea Trials testing. Distributed Workstations Not addressed â requirements are based on a centralized system with control from bridge and central control station (EOS). Requirements written around a system with distributed control possible to enhance survivability and allow password protected control of any system from any location. Uses domain concept to coordinate access levels of control and prevent conflicts. Elaborate hierarchy rules for different levels of userâs rights. Network Topology Basically just requires system to be arranged with redundant data paths where networks are required for essential services. Requires a switch mesh configuration, using the backbone cable plant topology, shall provide direct connections between each network switch, allowing multiple fault tolerant (logical or physical) pathways between each switch. Alternative network topologies may be considered for approval by the NTA. By virtue of connection-oriented data transport, the switches shall provide fault tolerant connections both within the backbone and user connection environments, in the event of a cable failure, data load imbalance, or switch hardware failure. Network Performance Two second response time, âdata overloads" shall not cause unacceptable delays in data transmission. Detailed criteria adopted from NSWC Network Design requirements. Network Redundancy No single point of failure, redundant data links required where same data link is used for two or more essential functions For a mesh topology, for N number of switches, N being less than five (5), each switch shall be connected to N-1 switches. For N greater than or equal to five (5), each switch shall be connected to three separate switches. Network Survivability Not addressed Survivability criteria are defined for Overall system Survivability, Backbone Switch to Switch Communications, Mission Critical User Communications, and Network Communications Redundancy. Additionally, there are more requirements for separation of redundant network cabling. Environmental Type Testing Must meet 19 environmental type tests based on IACS and IEC standards. See IACS Unified Requirements, E10 âTest Specification for Type Approvalâ9 Navigation equipment must be type tested to IMO standards. NVR also specifies these 19 environmental type tests, however, additional criteria must be met for EMC and shock. EMC criteria have been tailored heavily in NVR 2006 for naval vessels. 143 ABS Naval Vessel Rules (NVR) for Mission Critical Networks, Software Development, and Safety Critical Control Systems Author: Mike Roa, American Bureau of Shipping Topic SVR NVR Factory Acceptance Testing Basic system and equipment demonstration required to verify proper operation and fault tolerance. Navigation equipment must be type tested to IMO standards. Additional land based testing required for safety critical control systems and navigation systems. Stress testing is required to show that the system functions properly under worst case data loading. More requirements for land-based demonstration of failure modes to validate fault tolerance and stress testing. Dock and Sea Trials Basic demonstration of propulsion and steering control systems operation. For navigation systems, systems and equipment are operationally demonstrated during sea trials. More detailed test plan and test procedures must be developed and submitted to NTA for review and approval. Fault simulations and demonstrations of failure modes are required to validate redundancy and fault tolerance for R2N notation. Conclusions: The adoption of Internet Protocol (TCP/IP) based network technology and Open Architecture Standards to Navy control, navigation, and interior communications systems has resulted in highly integrated control and monitoring systems as well as fully integrated communications services including voice, data, and video while maintaining interoperability with legacy communication systems. The use of these emerging technologies has enabled the Navy to adopt a fully integrated, highly survivable, common network for all Mission critical functions, including control, navigation, and interior communications. The move towards Open Architecture standards has made it much easier for the Navy to upgrade systems with the latest Commercial off the Shelf technologies available. The major advantages of this Network Centric Navy approach are listed below: - Improved damage tolerance. - Ability to isolate/repair battle damage. - Ability to fight when hurt. - Improved situational awareness. - Improved ship safety. - Operational flexibility. - Reduced manning. - Improved supportability. - Reduced operating and support costs. Additionally, by committing to standardized system development processes, the Navy has greatly enhanced the quality and improved safety for their mission critical systems software while at the same time reducing the life cycle costs, and minimizing maintenance and system downtime, and enhancing system security through implementation of standardized Information Assurance procedures. 144
Comments
Copyright © 2024 UPDOCS Inc.