Why Maritime Cybersecurity Became a System Engineering Issue (6/9)
Chapter 6. Required Engineering Evidence
Why Maritime Cybersecurity Became a System Engineering Issue (6/9)
In the previous chapter, we explored why Explainable Design is becoming increasingly important in modern ship environments. We also discussed why implementing the required functionality alone is no longer sufficient, and why designers must be able to explain their design intent, operational assumptions, and engineering rationale.
This naturally leads to the next question:
"How can such a design actually be explained?"
In real-world projects, the answer to this question is typically found in various forms of documentation. However, the documents discussed here are not simply deliverables prepared for submission. They represent Engineering Evidence that explains:
- The engineering decisions that were made,
- The assumptions on which the system was designed, and
- The methods used to verify that the design performs as intended.
Ⅰ. Engineering Evidence Is More Than Documentation
In many projects, Engineering Evidence is often viewed simply as documentation that must be submitted. In reality, however, its purpose goes far beyond document collection. The more important question is whether it can answer questions such as:
- Why was this design selected?
- What engineering decisions were made?
- Which operational environment was assumed?
- Which design constraints were considered?
Ⅱ. Engineering Evidence Exists Throughout the Engineering Lifecycle
Engineering Evidence is not created at a single point in time. Instead, it is continuously generated throughout the entire engineering lifecycle — from initial design through operation and maintenance. Typical examples include:
Ⅲ. Different Stakeholders Need Different Evidence
An interesting aspect of Engineering Evidence is that not every stakeholder requires the same information.
Engineering Evidence is therefore not intended to satisfy everyone with a single document. Its purpose is to help different stakeholders understand the same system from their respective perspectives.
Ⅳ. Engineering Evidence Creates Traceability
Traceability is becoming one of the most important concepts in modern Cybersecurity projects. For example, if a particular security requirement exists, it should be possible to answer questions such as:
- How has it been reflected in the design?
- Which interfaces implement this requirement?
- How has it been verified through testing?
- How is it maintained during operation?
Ⅴ. Good Engineering Evidence Reduces Project Uncertainty
In many real-world projects, engineers often spend more time explaining existing documents than creating new ones. Typical examples include:
- Additional technical meetings
- Repeated clarification requests
- Design explanation sessions
- Test result reviews
Ⅵ. Engineering Evidence Is an Engineering Asset
The value of Engineering Evidence extends well beyond the completion of a Cybersecurity project. The same information can continue to support activities such as:
Closing Remarks
Engineering Evidence is playing an increasingly important role in today's Maritime Cybersecurity projects. Its purpose is not to generate additional documentation. Rather, it enables engineering teams to clearly communicate:
- Design Intent
- Operational Assumptions
- Verification Results
- Relationships Between Systems
in a manner that can be understood by all stakeholders. Ultimately, effective Engineering Evidence is far more than documentation. It represents accumulated Engineering Knowledge that supports system understanding, verification, maintenance, and future system evolution.
Engineering Evidence is not simply documentation to be submitted. It is accumulated engineering knowledge — the rationale, assumptions, and verification results that make a design understandable, traceable, and trustworthy across its entire lifecycle.
In the next chapter, we will explore how Engineering Evidence can be effectively prepared and utilized throughout real-world projects, and discuss the respective roles that shipyards and equipment suppliers should play in this process.
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