The Open Framework for the Simulation of Marine Vehicle Dynamics (OFSMVD) is an object oriented software architecture that is designed to provide a flexible and efficient architecture for developing a wide range of marine simulation applications. It can be viewed as two integrated sets of functionality intended to 1) support modeling rigid body motion and system dynamics, and 2) provide an abstract structural representation of the marine environment. The basic mathematical problem solved is the time evolution of one or more sets of coupled non-linear first order differential equations, expressed in state variable form. A large class of problems of interest to the naval architect and marine engineer can be represented in this form and there are numerous methods for solution, including Euler and Runge-Kutta methods for example. Three abstract software classes are defined by the framework to provide the generic behavior and interactions needed to solve the mathematical problem, System, State, and Solver. A System is an abstract object that behaves dynamically according to some governing equations, a rigid body or control system for example. A State object represents a time dependent, or state variable. It is related to a single equation from the set of those governing a dynamic system. A Solver object is used to advance the solution in time or iterate on a static solution.

　

 Meaningful representations of the physical world objects of interest in marine simulation are defined in terms of their software class counterparts. An Environment object is provided as a manager of all the other objects taking part in a simulation. The virtual environment could potentially contain objects that represent the wind, wave, and current fields as well as the above and below water topography. These objects are highly dependent on the nature of the application being developed and might have a high degree of interaction with each other. The Environment also contains the bodies and vessels that are moving about, each potentially interacting with each other and the wind, waves, current, and topography.

　

 The classes of objects that are defined by the framework have been developed and refined over several years. The result is an efficient, extendable, and powerful software model that is essentially independent of the form of models used, level of detail and fidelity required, and specific implementation details such as hardware platform, graphics subsystems, and process model (distributed applications, threading, etc.). This paper presents the formal software model for the framework using the Unified Modeling Language (UML) and discusses the class member function interfaces. A simple example is also presented that illustrate the use of the framework for simulating the rolling of a ship. The full source code to the framework, documentation, and several example programs are publicly available.

　

 The development of the software architecture presented in this paper is the result of a progression of simulator systems over several years. These simulation systems began as highly specific pieces of software, evolving to increasingly general use and greater capability. This progression is embodied in the MANSIM program lineage [1, 2, 3], and has been forged by both real and anticipated customer requirements. MANSIM started out as a ship platform dynamics simulation module for a team training simulator and was required to perform maneuvering, seakeeping, and stationkeeping. Over time, MANSIM remained a platform dynamics module, but the types of ships and their associated systems continued to grow. The final iteration of MANSIM resulted from the requirements of the COVE project [4, 5].

　

 The Conning Officer Virtual Environment (COVE) project was initiated by the Naval Air Warfare Center, Training Systems Division, in Orlando, Florida. COVE was intended to provide naval officers the experience of commanding a bridge crew performing underway replenishment. The virtual environment is displayed on a monitor or head mounted display while commands are processed by a voice recognition system. COVE imposed the additional requirement of multiple ships operating in close proximity to each other. The final phase of the COVE project, Phase II, extended the system to allow for harbor transits and berthing maneuvers. This required the ability to include the effects of tugs, shallow water, channel banks, and current sheer, among others.

　

 Each iteration and revision of the core MANSIM program code required increasingly complex modifications that cascaded throughout the code. By the time that COVE Phase 2 was on the horizon, it had become apparent that the MANSIM code, written in FORTRAN 77, was in need of a different approach to the problem. Anyone who has struggled with extending legacy simulator code will also have experienced the pain of the "cascading change" effect.

 The original concept for an object oriented solution to the general ship simulation problem was formulated during the 1993 MARSIM conference held in St. Johns, Newfoundland. In the years since the initial concept and the actual development of the framework to support the COVE project, many design cycles were performed and experimental implementations tried. The C++ language was always the choice for development of the framework because of its intrinsic support of object oriented programming, widespread support across many platforms and operating systems, a large base of tools (both C and C++), ease of integration with FORTRAN codes, and the efficiency of the code. With the advent of the C++ Language Standard in 1998, numerical/scientific extensions were incorporated into the language and the Standard Template Library, STL, was included as part of the language [6]. The STL provides highly efficient and flexible data containers and algorithms that rival hand coded, optimized versions. In fact, the language defines the STL containers and algorithms not just in terms of interface, but also in terms of performance. The numerical classes defined by the language are defined in terms of interface only, allowing compiler vendors to use whatever means they desire to achieve high performance. With the high level numerical and container tools defined by the language, a major limitation in developing a high performance and portable simulation framework was eliminated since they did not need to be created for and provided by the framework.

　

 There have been surprisingly few attempts in the marine simulation industry to leverage the capabilities of object oriented technology. Only one known published paper exists that has discussed the use of this technology for marine simulation [7]. At the time which that paper was published, development of the OFSMVD framework had already begun. However, it is interesting to note the similarities and differences. Both approaches abstract the concepts of a ship model and the components that apply forces on a ship. But the approach taken in [7] was focused on a particular end product - a ship handling simulator with particular interfaces in a distributed environment. The approach taken here is much more general and does not assume any particular end product or modeling method.

　

 Most naval architects and marine engineers have had little or no exposure to object oriented programming or languages. FORTRAN has been the historical choice for teaching engineers computer programming. The FORTRAN language promotes structured programming in which an application is defined in terms of functional units and the interactions between them. Object oriented programming defines applications in terms of the objects that are important for the application and their interaction. It is a subtle but important difference that takes time to appreciate. Definitions of the terms used in object oriented technology are useful here.

　

2.1 Objects and Classes

　

 The first question that must be answered is "what is an object?" The simple answer is that an object is an instance of a class, and a class is a defined data type [8]. For example, an oil tanker is a type of ship (class) while the Exxon Valdez is a particular instance (object) of an oil tanker type. One could say that an object has a physical existence (at least inside computer memory) and a class is a conceptual abstraction. Here, instance refers to the creation of an object, and the allocation of memory for that object.

　

2.2 Features of Object Oriented Programming Languages

　

 A programming language must support three features in order to be considered an object oriented language; encapsulation, inheritance, and polymorphism [8]. Encapsulation is the ability to define the data (properties or attributes) specific to an object, and the functions (methods) which operate on that data, within the definition of the object. For example, a ship object might have data particular to that object, such as speed and position. That ship object might also have methods that could alter the position due to speed. The data and methods for a particular ship object are not the same for any other ship object; they are specific to that one and only ship object. All other ship objects might have identical methods, but they operate on the data for their own particular ship object. The properties and methods that are encapsulated by an object are specified by the definition of the object type (i.e., the class). Note that encapsulation supports the concept of expressing has-a relationships, as in an object "has a" property.

　

 The second required capability is support for inheritance. This refers to the ability to define parent-child type relationships between objects and classes. These are sometimes referred to as super-classes and sub-classes. For example, a vessel class could have defined several child class types; submarine, container ship, or aircraft carrier. The point of inheritance is that a super-class can encapsulate certain data and methods while sub-classes can append their own specific data and methods. A sub-class could also override a parent's method to do something slightly or totally different. This is where the last language requirement, polymorphism comes into play. Note that inheritance expresses is-a relationships, as in a sub-class "is a" more specific type of a super-class.

　

 Polymorphism means that an object which is part of an inheritance relationship can behave (through its methods) in one of many ways, depending on the actual type of object. This capability allows the right method to be executed at run time. For example, in an application there may be many vessel objects created and they may actually be different types of vessels (sub-classes). Each type of vessel would define its own particular equations of motion within some method defined by the generic parent vessel type. The application, at a high level, would know that it has a collection of vessels and at some point would probably loop over the collection, instructing each vessel to execute that defined method. Polymorphism guarantees that the proper method representing the equations of motion for the actual vessel type is executed.

　

 How these three capabilities are implemented by an object oriented programming language vary from one language to another. However, from the simple descriptive examples presented so far, the powerful expressive capabilities of object oriented programming should be clear. It is worth noting that object oriented programming was born from the development of the Simula language in the 1960s. Simula was a language designed to perform discrete event simulations [8]. The usefulness of object oriented programming concepts to continuous time simulation should therefore not be too surprising.

　

2.3 Unified Modeling Language

　

 The Unified Modeling Language (UML) is a standardized descriptive language for expressing the design of object oriented systems and is independent of implementation language (C++, Ada, Smalltalk, etc.). It is designed to represent the relationships, associations, interfaces, and behaviors of, and between, objects, classes, and components [9]. UML is graphical in nature and describes relationships, associations, etc. by a variety of different diagram types, including class, object, sequence, component, collaboration, and deployment, among others.

　

 In order to illustrate the basic model of the OFSMVD framework, only simplified class diagrams will be used. In a class diagram, each class type is represented by a labeled rectangle. Connecting lines between the classes are used to represent the relationships among the classes. Table 1 gives the meaning of the symbols used in the connections between classes.

　

　

 Associations represent a structural relation between classes. The arrowhead indicates the visibility of the class between each other. In this case the associated class is visible to the class but the class is not visible to the associated class. A general association does not imply any particular mechanism for implementing the association.

　

 An aggregation relationship represents an asymmetric association in which one side plays a more important role than the other, in the relationship. The arrowhead indicates visibility, as with an association. Aggregation also implies that the lifetimes of aggregated objects are not managed by aggregate objects.

　

 Composition relationships are a particular case of aggregation. It implies physical containment of the composite class (attribute) and that the lifetime of the composed class is controlled by the composing class. Again, the arrowhead indicates visibility of the related classes to each other.

　

 Association, aggregation, and composition relationships can have a multiplicity defined for the relationship. The multiplicity defines the number of, or range of numbers of classes that are involved in the relationship. In this way, one to one, one to many, and many to many relations may be expressed. Multiplicity is indicated on the diagram by a numerical value at the connecting end, or by a symbol such as ^* to indicate any number.