Why Maritime Cybersecurity Became a System Engineering Issue (5/9)
Chapter 5. From Functional Design to Explainable Design
Why Maritime Cybersecurity Became a System Engineering Issue (5/9)
In the previous chapter, we explored how IACS UR E26 and E27 were introduced — not simply to impose new cybersecurity requirements, but as an industry response to the growing engineering challenges associated with increasingly complex ship systems. However, another important change has also begun to emerge: the way design itself is viewed.
In the past, the primary objective of system design was to implement the required functionality. Today, however, it is no longer sufficient to simply deliver a working system. Designers are increasingly expected to explain the rationale behind their design decisions and demonstrate that those decisions can be verified.
In other words, it is not only the subject of design that has changed, but also the way design itself is viewed.
"Why is the traditional design approach no longer sufficient?"
Ⅰ. Functional Design Was Sufficient in the Past
Traditionally, the primary objective of ship system design was to implement the required functionality. This approach proved highly effective in environments where systems operated largely as independent equipment — once the required functions had been implemented and verified through testing, most engineering requirements were considered satisfied.
Typical design questions included:
- Can sensor data be collected correctly?
- Are control commands executed properly?
- Are alarms generated as intended?
Ⅱ. Modern Systems Raise Different Questions
Modern ship systems, however, continue to raise new questions even after the design has been completed. These questions cannot be answered simply by describing system functionality — they require an explanation of the engineering decisions, design assumptions, and rationale that shaped the system architecture.
For example:
- Why was a particular CBS (Computer-Based System) assigned to this Zone?
- Why does this system require remote access?
- Why is only selected data allowed to cross Zone boundaries?
- Why is one interface permitted while another is restricted?
Shipyards and equipment suppliers have decades of experience designing and manufacturing systems that satisfy functional requirements. Yet in today's cybersecurity projects, they are increasingly asked questions that go beyond functional implementation.
Ⅲ. Design Decisions Become Engineering Evidence
Since compliance with IACS UR E26 became mandatory for newbuild vessels contracted on or after July 1, 2024, shipyards and equipment suppliers have increasingly encountered the following situation: the shipyard requests additional engineering information from the supplier — but the supplier believes that functional specifications and test reports have already been provided.
What the shipyard is actually looking for is a different type of information — not additional functionality, but Engineering Evidence that helps explain and validate the existing system design:
Ⅳ. Explainability Improves System Integration
The primary objective of Explainable Design is not to produce more documentation. Its real purpose is to reduce uncertainty during system integration.
For example, a supplier may explain that its CBS operates correctly. However, the shipyard must also understand how that CBS interacts with other systems within the integrated vessel environment. When the design intent and operational assumptions are clearly documented:
- Misunderstandings can be minimized
- Repeated technical discussions can be significantly reduced
- Integration risk is reduced across the shipyard-supplier boundary
Ⅴ. Explainability Supports Verification
Verification is far more than simply performing functional tests. It is the process of confirming that the implemented system behaves exactly as the designer originally intended.
For Verification to be meaningful, the design intent must first be clearly defined. Without clear answers to the following questions, tests may still be executed — but it becomes difficult to conclude that the design itself has been properly verified:
- What exactly should be verified?
- Under which operating conditions?
- What defines acceptable system behavior?
- What are the allowable operational limits?
Without a clearly defined design intent, a test can confirm that the system runs — but cannot confirm that the system behaves as intended under the conditions the designer assumed. Explainability is therefore a prerequisite for meaningful verification, not an add-on.
Ⅵ. Explainable Design Is Not About More Documents
One of the comments most frequently heard during cybersecurity projects is: "Are we being asked to produce too many documents?"
In reality, the quantity of documentation is not the primary issue. What matters far more is whether the existing design can be clearly understood. Even for the same system, if the following elements are adequately explained, many unnecessary follow-up documents and technical discussions can actually be avoided:
- Design Intent
- Operational Conditions
- Design Constraints
- Recovery Strategy
- Interface Relationships
Closing Remarks
In today's ship environments, implementing the required functionality alone is no longer sufficient. Modern ship systems must also be capable of answering why questions:
- Why was this design selected?
- Which operational assumptions were made?
- Which design constraints were considered?
- On what basis was the design verified?
- What operational impacts were anticipated during failure conditions?
Only when these questions can be answered systematically does a design evolve beyond Functional Design into Explainable Design.
Designing a system is no longer enough. Today, the design must also be understandable, explainable, and verifiable. Explainable Design is not about adding documentation — it is about organizing existing engineering knowledge into a form that others can trace, challenge, and confirm.
In the next chapter, we will explore how Explainable Design can be supported throughout real-world projects — and why Engineering Evidence is becoming an increasingly important element of Maritime Cybersecurity.
Practitioner at the intersection of maritime OT security and IACS UR E26/E27 compliance. Writing the Blue Horizonist series to bridge the gap between regulatory language and real-world engineering decisions at shipyards and aboard vessels.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment