USMOOTH: A SAFETY MONITOR DEVELOPMENT PROJECT
The lead for the USMOOTH project was ASV Global LLC (now L3 Technologies), a leading unmanned surface vessel designer and manufacturer. We also had project partners from Cranfield University. The aim was to enable an autonomous vessel to be remotely operated in various scenarios.
This included sea bed mapping and infrastructure monitoring. ASV build and operate remotely controlled vessels and wanted to be able to safely operate these from an operations centre rather than control the vessel visually. This meant the use of a risk- based algorithm to control the path of the vessel, which needed to be accurate and efficient, but it was recognised that there were limitations on this algorithm for making safety claims.
While such algorithms can provide significant benefits, it is also known that they may fail to come up with a solution to a path- planning problem in time, or indeed, at all. D-RisQ was asked to provide a safety monitor that would ensure that the vessel always complied with the rules-of-the-sea for collision avoidance; these rules are known as COLREGS. Appropriate sensors were needed to provide information upon which a decision could be made.
Autonomous Surface Vessels Obeying COLREGS - YouTube
Architecture
The system architecture was developed which enabled the right safety claims to be made. This included allowing an operator to take control for launch and recovery. There were a number of scenarios where operators would not realistically be able to control the vessel, hence the need for the safety monitor.
For example, the communications to the remote vessel have to be via satellite, which brings a number of constraints. There is around a 4 second delay for the return journey of information from the vessel to the operator and the response from the operator to the vessel; roughly 1 second for each up and down link. A major concern was the avoidance of debris that could simply pop-up and present an imminent threat to the vessel. There might be insufficient time for an operator, even assuming an instantaneous response to information received, to avoid such situations.
Hence there was a need to allow the vessel to operate autonomously and safely choose a new path. In a more general sense, it could not be guaranteed that the risk- based path planning algorithm could, in all circumstances, correctly avoid other sea traffic, so a safety monitor was also needed.
Finally, communications presented a series of practical and economic problems: it is difficult for remote operators to gain situational awareness from the available information; there is a significant cost for bandwidth to present a detailed enough picture from various sensors hence some compromise is necessary and this affects the ability of the operator to gain situational awareness; and of course, the communications link may fail for a variety of reasons. It is also recognised that watching a rather grey screen for hours at a time is dull work and attention may wander thus there is a significant case to enhance operator effectiveness by making the safety aspects remote from the operator. All of these issues and hazards meant that there was a need for high integrity decision making software that would take control of the vessel in order to maintain safety.
The architecture also had to consider the ability of various types of sensor to provide the information upon which to make decisions and how these sensors are affected by sea state and weather conditions. We also considered whether and how to account for on-board failures and decided that only certain major faults would be factored into decision making.
Software Standard
There is no maritime specific software standard. As the base safety case will have goals that need to be met, it was decided that the best approach would be to use DO-178C. This is a rigorous standard that is applied to fleets of aircraft (rather than one-off instances) and would be a sound rationale for use with fleets of unmanned vessels. D-RisQ would be building automatic formal verification technologies throughout the project so DO-333, the Formal Methods Supplement to DO-178C would be employed. In fact, DO-330 would also be used as part of the guidance for the development of the verification tools.
DISCOVER MORE
Requirements
The system behavioural requirements for the safety monitor were developed in a series of workshops. A System Requirements Document was written, reviewed and approved by the consortium. Note that these requirements covered many different facets of the vessel, the use case, the COLREGS and the environment and included safety requirements that had to be met. The System Requirements were then developed by D-RisQ into a set of Software High Level Requirements (HLRs). At this stage, Kapture® was still in development, but a prototype had been developed that was partially used in the project. The semantics for a set of templates had been developed so we knew that we had sufficient expressivity for use by 3rd par ties in a future tool. The HLRs were reviewed against the System Requirements and hence we could claim that the appropriate DO-333 objectives had been met.
DISCOVER MOREArtificial Intelligence, Safety and Costs
This project provided D-RisQ with the knowledge of how to produce safety monitoring software for embedded real time systems that exploit risk based or AI based software. It means that we can allow the benefits of AI without having to worry about the safety of AI. We provided a route to independent, high integrity decision- making software that allows safe operations of the unmanned vessels over-the-horizon. We did this at very low cost and showed how we would comply with internationally recognised software standards. Our approach is therefore, an enabler of AI systems, as we showed that we can provide the required trust in such autonomous systems at a cost that is affordable'
WANT TO LEARN MORE ABOUT Kapture®?
Privacy Policy | Terms & Conditions
Drisq Ltd 2024. All rights reserved. Design by Design in the Shires
