Paul R. Walters, Assistant Chief Engineer, ABS, explained why ‘Smart Ships Demands Quality Software and Cyber Security’ during the 2016 SMART4SEA Forum. He highlighted the need to improve software quality onboard marine and offshore assets. He addressed cybersecurity and Cybersafety pointing to four key elements for achieving safety and security objectives: traceability, documentation, transparency and verification. He explained that these requirements are self-evident and continue beyond the initial build into the maintenance phase. Mr. Walters concluded his presentation advising that it is critical to understand how updates will be integrated as well as the global impact individual equipment updates can have on the full-integrated system.
For enhanced Cybersecurity, there is need for Software Quality which is built into good architecture. Right now, our industry is in arts and crafts area. We need to get out of that and get into engineering software.
Classification societies offer a number of notations for software quality. ABS has the Integrated Software Quality Management (ISQM) and Systems Verification notations. We also have an ISQM conformity program. We go to the vendors and ask them how they develop their software and how disciplined they are in maintaining them.
On a good software project, 40% of total project time is ‘requirements gathering’ which includes the functional requirements as well as the implicit requirements, proving availability and repeatability. It is very important that the owner be involved and that all the failure routines are described thoroughly. On a recent ISQM project , the initial description of the software that was given and accepted by the owner was 43 pages. At the end of that job, after ISQM was applied, he received 158 pages from the vendor. This is significant because the documentation was fora very important piece of equipment. Best guides and notations follow international recognized standards (ISO: 12207), and these include multiple suppliers because of the integration. Interoperability is also very important as we have automation onboard ships. Also, more and more registers are now being shared from different vendors. This means that it is possible for one vendor to come on board and make a change to its software that could fix the problem but break the system. If the vendor breaks the system, the new ship may not be able to carry out its mission.
Classification of smart ships is likely to be universally required. IMO and USCG are talking to us about that, and of course we are involved in IACS. The goal is to verify that safety is not compromised by automated systems. ‘Smarter’ ships reduce some risks, but can increase others. There are many benefits, but they introduce additional risks. One of them is the complexity that goes along with more and more automated systems, and you also have systemic failures where one piece of equipment fails and then the whole network goes down because of chatter.
|Data supports analysis, sensors may increase in number||Exposure to unrecognized risks through interfaces (internal & external)|
|Task automation||Complex to build & deploy|
|Faster reporting with more sensors & equipment||Automation bring risk (Safety, Environmental & Business)|
ABS CyberSafetyTM, trademarked by ABS, includes:
- Traceability of system design, test, implementation and evolution
- Documentation (evidence) of software quality engineering processes
- Transparency in…
- Development processes
- Delivered functionality
- Failure mode, risk and recovery
- Maintenance and support
- Verification of
- Established engineering processes
- Component and system (integration) test
- Security (evolution and cyber)
Cybersecurity begins with quality software and system architecture. Engineered software requires engineering discipline and the application of cybersecurity principles. That’s where industry actually runs into issues. Sometimes there is a change in the code that does not get documented. And that has to be addressed.
Software must be:
- Thoroughly documented
- Have functions that are traceable
- Assessed (FMECA, FMEA)
- Normal and failure programed actions
- Cyber vulnerability assessment
- Failure dependencies or cascade failures
ABS is committed to:
We need more documentation; we need traceability on all those functions. In the failure mode, we also need to assess every bit from the safety aspect as well as the normal and failed programmed actions. We also need to do an assessment for cyber vulnerability and look for cascading failures. And the software must be testable. The software updates should follow the exact same process.
Above article is an edited version of Mr. Paul Walters presentation during the 2016 SMART4SEA Forum
Please click here to view his video presentation
The views presented hereabove are only those of the author and not necessarily those of SAFETY4SEA and are for information sharing and discussion purposes only.