This project has been carried out at the request of a commercial organisation, the Port of Southampton, which is owned by Associated British Ports (ABP). The process of planning the exact berthing position for every vessel is complex, therefore it is desirable to have a computer-based tool to assist in decision-making by the Berthing Officer. The project was previously attempted by MSc students, but the results did not quite match expectations.
While taking note of the previous projects’ conclusions it was found that there were underlying trends that would have made it impossible to bring the project to a successful result by just following the recommendations.
A new requirements analysis was carried out, and the evolutionary model of software development was followed. The applications used were Microsoft Access and Visual Basic. During the course of the project unexpected results were discovered regarding applications and their uses.
What has been produced is a relational database and a mapping tool both of which were successfully demonstrated. These elements comprise the overall Berthing Tool. As this is still in a middle stage of evolutionary development there is still further development to be done to achieve full implementation.
However the alpha version clearly demonstrates the feasibility of the project and forms the core for further development.
I would like to express my thanks and appreciation to my academic supervisors, Ms. Kate Viscardi and Dr. John Yates for their support, guidance and enduring patience throughout this project.
Also, I would like to thank my industrial supervisor, Mr. Alex McKechnie from the Berthing Office at the Port of Southampton for his support and patience in answering all my questions.
1.1 The Present Environment
1.2 Structure of this report
4.2 Present Berthing System
5.1 The Requirements Engineering Process
5.2 Methodology for Analysis
5.3 The Requirements Analysis
6.1 Requirements to Meet Project Aims/Objectives
6.2 Required Berthing System
6.3 Requirements Analysis
6.4 The Role of the Berthing Officer
6.5 Evaluation of Previous Work on this Project
7.1 Software Development Methodologies
7.1.2 The Waterfall Model
7.1.2 Evolutionary Development
7.2.1 Relational Databases
7.2.2 Microsoft Access 97
7.2.3 Object Orientation
7.2.4 Visual Basic
7.3 Computer Graphics
7.3.5 API Functions
8.2 The Database
8.3 Output Design
8.4 Imaging Techniques
8.5 The Graphics
8.6 Report on Demonstration
9.2.2 An Analysis of Applications
This project has been carried out at the request of a commercial organisation. The Port of Southampton, which is owned by Associated British Ports (ABP) handles 55,000 vessel movements a year and traffic is increasing. The process of planning the exact berthing position for every vessel is complex, therefore it is desirable to have a computer-based tool to assist in decision-making by the Berthing Officer.
MSc students have previously attempted this project. However all came from a Computer Science background and difficulties were encountered with the complex four-dimensional nature of this project. It was felt that a student from an engineering background and with sailing experience would stand a better chance of success. Because the project encompasses both requirements analysis and technical aspects, neither of which is straightforward, two supervisors are jointly responsible for the project.
The Port handles 55,000 vessel movements a year, with turn-round times increasing. All vessels are uniquely configured and each needs to be berthed in the appropriate position for offloading. The planning of the vessel's position entails identifying exactly where it should come alongside and determining the correct position of the moveable fenders, or dummies. Approximately 4000 vessels use the port on a regular basis. For each of these, positions have already been worked out and verified.
However, new arrivals have to be planned from scratch, as do current users coming in to a different berth and positions may be able to be modified to avoid unnecessary (and expensive) movement of fenders. Currently, all planning is done manually by the Berthing Officer on watch but the process is time-consuming and the growth in traffic creates a demand for planning to be speeded up. Therefore the Port has requested a computer-based decision-aiding tool.
Ideally the tool should show the plan of the port and enable vessels to be mapped to it. It is also desirable that it provides a means to move vessels to fenders and not vice versa, if possible.
Because of the nature of this project, it was agreed with one of the supervisors that the standard headings for a project report would result in much duplication and make it difficult to follow the progress of the work. Therefore the report headings follow the chronology of the project work, with an indication in each heading of which components of the standard format are contained therein.
To produce the alpha version of a tool which enables the berthing officer to plan efficiently the berthing positions of vessels incoming to the port. This tool is to include a database and graphical mapping tool in addition to user instruction
To demonstrate the alpha version to managers of the berthing function.
In addition to the above, the following will be incorporated in the project report:
A further aspect of the project was delivered on the 19th December 2000 at the Port of Southampton in the shape of a demonstration of a preliminary version of the software.
Fig.1 Flow Chart for Present Berthing System
(incorporates part of Technical Approach)
This section investigates the current berthing system and analyses the previous projects and where the results did not meet the requirements. While examining applications and methodologies used the emphasis shall not be so much on definitions and explanations but will rather focus on why and how the results did not meet expectations and suggest possible alternatives and approaches that might be more successful.
One background examination shall be that of requirements analysis, a central theme of requirements analysis is feasibility and if this can be determined then the successful conclusion of the project might be achieved (Sommerville 1995). A brief explanation of Access and Visual Basic, in addition to graphical tools will also be reviewed but only within the relevant context of project necessity, that is, the main requirement of the berthing officers.
A detailed academic background to this work is given in the next Chapter.
The berthing system operates within the wider context of the Vessel Traffic Services. In 1999, a new vessel movements system was introduced. This Port and Vessel Information System (PAVIS) was written by Logica and is now managed by ABP's central IT support function. This introduction was rapid because the old system was not Y2K-compliant, and the positioning of vessels was outside the remit of the requirements for PAVIS. Berths are allocated by the Operations Department and recorded on PAVIS, but the actual positions are determined by the Berthing Office.
The present berthing system now receives information from PAVIS regarding vessel movements and berthing allocations. The shipping agent informs the VTS centre of the vessel using the port, giving details of the ship, including ETA (Estimated Time of Arrival) and ETD (Estimated Time of Departure). Booking and allocation can be done from 48 hours to a year in advance.
Berth allocation is planned according to the requirements of a particular vessel. These include the type of cargo, loading/unloading limitations, ramps and any operations requiring the use of cranes and other lifting equipment. Note is also taken regarding the present positions of fenders so that ideally the vessel can be matched to fenders in order to save costs for moving fenders (Fig 1).
The optimum placement of the vessel is then determined with regard to the above requirements and this is then the standard position.
In addition to planning vessel positions, the berthing officers also supervise and record the actual arrivals and departures. The berthing function is therefore staffed continuously, 24 hours a day, 365 days a year. There are usually four berthing officers in post, with one on duty at any time.
The cards used for the berthing system contain the vessel’s details, length, beam, bridge position and stern in addition to draft and other details of the vessel’s configuration on the front side. On the reverse side are the standard positions. Vessels that have visited the port will have one or more standard positions; if not verified they are pencilled in.
There are four principle stages in this process:
1. Feasibility Study – An estimate is made whether the identified user needs may be satisfied using current software and hardware technologies. The result should inform the decision of whether to go ahead with a more detailed analysis.
2. Requirements Analysis – This is the process of deriving the system requirements through existing systems, discussions with users, task analysis and so on. System prototypes may also be developed to help understand the requirements.
3. Requirements Definition - Requirements definition is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. These should accurately reflect what the customer wants.
4. Requirements Specification - A detailed and precise description of the system requirements is set out to act as a basis for a contract between client and software developer.
According to Sommerville (1995) there are two main methodologies for requirements analysis:
This is used for medium to large systems that have many types of end users from differing fields. An example of this would be a bank, which has a wide range of staff ranging from bank managers to tellers, database administrators, and of course account customers. All these would have differing viewpoints as to user requirements.
This is probably the most widely used approach to requirements analysis. It depends on the application of a structured method to understand the system. The results of the analysis are expressed as a set of system models defined by whatever method is being used. Analysis methods have different emphases. Structured methods includes some or all of the following:
Fig2 The Requirements analysis process
There are six process activities involved, which can be viewed
as a cycle, they are iterative with continual feedback from each activity.
A visit was made to the Port of Southampton in order to view and analyse the current berthing system, and then critically examined this from the Berthing Officer’s viewpoint. A critical examination and evaluation of previous project with particular reference to reasons of failure to achieve objectives was also performed.
A computer and relevant software applications to enable objectives to be achieved was also necessary. Applications and tools were researched and examined to determine the optimum method for the berthing tool needs.
Access to supervisors and technical support to discuss problems and access to the Berthing Officer for specific berthing information; namely, size and types of fenders and bollards was also a requirement.
Available literature was reviewed critically. Given the circumstances, it was decided the requirements necessary to meet project aims could be met, since the programming could be done on a personal computer.
The required berthing system was based on the following:
The requirement statement was derived from the original requirements analysis project. This was to:
This was redefined into a new flowchart, which is very similar to the present system, only differing in the replacement of the cards with the database.
A requirements analysis of the present berthing system with particular reference to the role of the Berthing Officer has been carried out following a visit to the Port of Southampton on the 18th April 2000.
An evaluation of graphical methods with reference to hydrographics and cartography is necessary. In addition, graphical representations and measurement techniques must be examined.
The previous project recommended a requirement of a database and a mapping tool. The requirement for the mapping tool did not however specify a berthing accuracy of 1 ft. This is within the domain of the mapping tool, which is a later stage of the project. For the present, the first stage of the project shall be examined; that is the database, and how this may be applied to reflect the present berthing system when using a computer-based tool.
It was decided to use a method-based analysis since there was only one viewpoint to consider, and structured methods were required. However, in one respect the viewpoint analysis was used since the emphasis of the role of the one viewpoint, namely the berthing officer, was essential. Of the structured methods available, the
process model and system modelling notations (Sommerville, 1995) were used.
Fig5 Flow chart for berthing system
A visit to the Port to meet the industrial supervisor and observe the methods used for berthing vessels was carried out, with academic supervisors present. This resulted in a requirements analysis being carried out.
The role of the berthing officer is central to this analysis since the present berthing system has been in place since before the advent of computer systems. While the previous and current IT systems have had an impact on the transfer of data to the berthing officer, the core system has remained unchanged.
When the booking is taken from PAVIS, the berthing officer looks at the appropriate card for that vessel, the front of which contains the vessel’s details, length, beam, bridge position and stern, in addition to draft and other details on the vessel’s configuration. On the reverse side are the standard positions. Vessels that have visited the port will have one or more standard positions; if not verified they are pencilled in.
There are two reasons for planning a new berth. One, the vessel is a first time visitor to the Port, or two, the vessels has one or more standard positions but none are available. While both reasons are similar, the effect is the same; in either case a new standard position will need to be planned.
A vessel entering for the first time naturally will not have a standard position. There are two options to follow. If the vessel is unplanned a berth will not have been booked, but in either case, the first port of call is the list of standard positions on the cards. If booked, then check for a standard position for that particular berth; if not then check if any berth with a standard position for that vessel is available.
Should there be no standard position available, a standard position is calculated. A 1:500 scale drawing of an available berth with the aid of a ruler achieves this. The drawing includes fixed structures on shore; the berthing officer draws ramps on the vessel and dummies (fenders). The vessel (loosely represented by the ruler) is manoeuvred to obtain an optimum placement alongside the berth, taking care to avoid any obstacles. This is somewhat awkward and time consuming since care must be taken to ensure an accurate (within 1 ft.) and consequently safe position.
The position is calculated using the bollards as a fixed shore-based reference relative to fixed points on the vessel, namely the bow, bridge, and stern.
For the Bow: 8 is the bollard number; 40 is the distance in feet from the bollard. Therefore the bow is 40 ft. to the left of bollard 8 when viewed from the vessel. These numbers are placed on the planning board, in addition to the type and placement of the fenders used. The orders to dress the berth are then sent.
When the vessel is due this information is copied onto a berthing note and taken to dock where the berthing officer marks off 12 ft. from bollard 7 (lines are drawn every ft.) and uses this as the bridge position. This is similar to the required berthing system (Fig 5).
This is a software project that has been in a process of development since 1997. The original requirements analysis was first written in 1998 with the original computerised database known as Trident, a replacement for the older VTMIS system. This in turn has since been replaced by PAVIS, an acronym for Port And Vessel Information System. The PAVIS system is a database written in Access that includes vessel characteristics and movements for all Associated British Ports. The Berthing Officer uses this information as a basis to determine the optimum berth for the appropriate vessel.
This analysis is based partly on previous sources, but primarily on first-hand experience arising from a visit to Southampton port on 18th of April 2000 where the activities and methods of the Berthing Officer when planning vessels were closely observed.
Comparing the previous project (Abdelrahman 1999) with the results produced one of the major problems found was the incompatibility of Visual Basic with Autocad. This resulted in the program falling short of expectations. The recommendations were to use the Visual Basic graphics environment in conjunction with an Access database as a solution.
However, on closer examination, this by itself would not meet the requirements. The previous project was designed around the graphics, that is, a map of the Port (Port Handbook 1998). A database consisting of two entities (tables) was developed, and the graphics were designed to ‘zoom in’ to the required scale. This was overly simplistic and used the premise of using the application to solve the problems.
This was due to expecting the applications, Autocad and Visual Basic in this case, to be able to do the job of ‘zooming in’ to the required scale without taking into account how this was to be done. Additionally, there was no method for measuring on the required scale or even how this might be achieved.
Fig.6 Data-Flow Diagram for Present Berthing System
Although a previous requirements analysis recommended using a database in conjunction with a mapping tool, the reasons leading to this conclusion using the requirements methodologies for a method-based analysis, must be re-examined.
The berthing officer’s activities follow a set pattern, which is a system in itself and only influenced by the input from without when the requisite activity is required to plan a berth (Fig 6). Determining the optimum placement of the vessel by means of standard positions is wholly within the purview of the berthing officer.
When looking at the system separation of concerns are examined. The Calculate box forms the basis of a berthing tool. This is where the required calculations to determine the relative positions of the vessel to the bollards are carried out. As the berthing officer moves the vessel on the screen, the position of the vessel is calculated to the nearest bollard to the right when viewed from the vessel. These figures are given in feet from the bow bridge and stern positions on the vessel.
The other boxes move data but do not otherwise change it. With this further concerns may be separated such that there are now two entities, one of which should assist in performing the central role of the berthing officer, that of determining standard positions. The others may be combined into a database which will manipulate data so the relevant data for the berthing tool can perform more tasks.
The result of the above analysis is to develop a relational database management system which reflects the current berthing activities and can be expanded to include additional tasks such as the time domain. At present, the berthing tool can be envisaged to have three dimensions – two plane dimensions and a ‘depth’ dimension to represent the small scale berthing process. A time factor would add the fourth dimension.
The output from the database queries can be applied graphically, once the requisite data has been collated and sorted into the appropriate order.
While it was originally envisaged to use the waterfall method (Sommerville 1995), it became evident from the scope and complexity of the project that an evolutionary model was required. The exploratory model (Sommerville 1995) was used since the first requirement is to find a method to satisfy the customers basic requirements, that is, computer model of the role of the berthing officer. Subsequent additions are subject to further review.
So far the background relevant for this project has been examined. Requirements analysis was examined and the recommendations to use Access and Visual Basic applications was considered and accepted. A critical examination of the previous project was carried out. However, it is possible that there are further underlying reasons for the previous project not meeting expectations. This can only be examined in the light of further development of this project.
Fig3 The software lifecycle
There are four fundamental process activities which are common to all software processes (Sommerville). These are:
There are two main software process models that are relevant to this project.
Fig4 Evolutionary development
This takes the above activities and represents them as separate process phases such as requirements specification, software design, implementation, testing and so on. After each stage is defined it is signed off and development goes on to the following stage (Fig3 ).
Evolutionary development is based on the idea of developing an initial implementation, exposing this to user comment and refining this through many versions until an adequate system has been developed (Fig 4 ). Rather than have separate specification, development and validation activities.
There are two types of evolutionary development:
This section is based on knowledge gained on a course at Microtech Computer Services and direct experience.
Microsoft Access 97 is a database application that uses a Relational Data Base Management System (RDBMS). It is not a requirement to use Access in this manner but for the sake of logical organisation it is usually implemented in this fashion.
Historically, relational databases were first developed c1970 for two reasons; one, to avoid unnecessary duplication of data thereby saving storage space; and two, to ensure security and coherence of data by having only one instance of any particular data set thereby avoiding contradictory data.
In the past, large companies would have multiple data storage facilities, such as magnetic tapes and disks, in various locations, most holding the same data in different formats. An example of this would be bank records, where different accounts for the same customer would be held in different locations, but all having personal details, i.e. name and address at every location. So a change of address on one storage device would not necessarily mean a change of address on the other devices thereby causing mail sent to the wrong address.
The primary reason for relational databases was to save storage space. This was in a period when any type of electronic storage, (archaic devices such as punch cards and paper tape shan’t be mentioned) was at a premium. RAM memory was in the 10-40 kb range and electronic disk storage a few Mb. A well known example of the consequences being the Y2K problem or “millennium bug” where a major crisis costing billions was imminent because in the 1970s saving two digits of memory was important.
The present days of 128M RAM and disk storage in Gigabytes, means that the original reason for relational databases is no longer a major concern. However, it is still applicable to avoid duplication of data for reasons of continuity and more importantly, for referential integrity. This ensures the unnecessary duplication of data by using only one instance of a particular record, such as a name, by assigning a unique number, known as the primary key. Searches using the keys as an index are far faster since the number is a pointer to a memory store.
There are six main components of an Access database (MS Access Help Files 1997):
use Access at least one table must be created.
The term “object-oriented” means that we organise software as a collection of discrete objects that incorporate both data structure and behaviour. This is in contrast to conventional programming in which data structure and behaviour are only loosely connected. (Rumbaugh 1992)
There are generally four aspects or characteristics:
Visual Basic is an object-oriented application used with Microsoft Windows. It has the Integrated Development Environment (IDE) within which Visual Basic is developed, compiled and run. It has menu items, tool bars, as well as containing other windows involving dialog boxes, icons, command buttons, text boxes and more tool bars.
The designer or developer places objects on a window called controls. These activate the requisite event procedures. Visual Basic consists of a set of instructions known as event procedures. These can be anything from a mouse click to a pre-defined instruction that activates the event.
There are three steps in creating a Visual Basic program:
Visual Basic also has its own graphic capabilities that are utilised by clicking the appropriate icon on the toolbox.
All graphical displays are based on points or pixels on the screen arranged in rows and columns. How these displays are interpreted and stored are of particular importance to this project.
There are two main graphical representations relevant to this project, which concern us.
Short for picture element, the smallest and most commonly used screen-dependent measure of screen distance. This is one spot in a rectilinear grid of thousands or even million of such spots that are individually painted to form an image produced on the screen by a computer or on paper by a printer. Just as a bit is the smallest unit of information a computer can process, a pixel is the smallest element that can be displayed on a computer screen. In terms of physics this can be likened to an atom. While the “atomic” size may vary according to screen resolution, in practice this is not divisible. It may also be regarded as a “quanta” of screen size. Objects on a form, however, generally aren’t sized and located via pixels because the number of pixels on a screen varies for different resolutions and for different types of display.
This is a screen-independent measure of screen distance equal approximately to 1/1440 of an inch. Objects on a form are sized and located by using twips instead of pixels so that they appear similarly on various types of display systems. (Reselman & Peasley 1999)
In photography, zooming means that an image is magnified using a lens so that the object or view appears closer and more detail can be seen. Similarly, a microscope performs the same task. On a computer screen, this also appears to be the same event. However, there is a major difference in how this is applied and the results are not of the same degree as that in lens magnification.
The Applications Programming Interface (API) is a set of functions that are exposed by a software module and provide access to the services the module provides. In Windows, the API is a set of core functions that allow direct access to many operating system-provided services, such as window management and graphics functions. There are two graphic functions of interest; the polyline and the polygon.
This section includes the project approach, an examination of methodologies used and functional specifications of both the database and berthing tool.
Originally it was thought to use the previous projects’ software and re-write it so it meets the requirements. One of the possible solutions put forward regarding excess storage space for the vessel drawing was to have similar vessels using the same drawing, reducing the number of vessels drawn.
In retrospect the reasons for not meeting the requirements were rather more complex, regarding the many aspects of the project and also quite simple, regarding the approach to the problem.
Technical aspects in the design of the database and berthing tool will be examined and the reasoning for the methods used.
The result of the requirements analysis was to divide the project into two parts:
The database was designed and written first since there was a problem installing Visual Basic. Also, the nature of the analysis dictated a first approximation of database design since the relationship of the vessels to the standard positions and the port was the main concern and the graphics (at this stage) was secondary. There is no need to go to graphics every time.
Fig7 Entity Relationship Diagram
Fig8 Output Form Design
The design of the database reflects the current berthing system insofar as the vessels and standard positions are concerned. As on the card system, every card represents one vessel with standard positions on the reverse side.
The bollards table is also used to determine the relative positions of the bollards, this in turn will be used for the graphics. The bollards are also given a unique identifier since the bollard numbering system is not always consistent. The fenders table lists all the fenders by type and position, the key requirement being that all fenders are attached to a bollard, on the reasonable assumption that fenders floating around unattended would constitute a navigational hazard.
This consists of four entities (tables) and two pairs of relationships; primarily the Vessels and Standard Positions where every vessel has between 0 and >1 standard positions in a 1 to Many relationship. Similarly, the fenders and bollards tables have a One to One relationship (Fig 7).
The primary key for the vessels is the Lloyds registry number, known as the IMO number (International Maritime Organisation).
A data dictionary of the tables is given in Appendix A.
The output design again reflects the present role of the berthing officer (Fig 8). The initial switchboard screen opens displaying a choice of menu (future versions). The one of particular concern is the standard position. This opens the find vessel form, where the appropriate vessel is found. This in turn displays the standard positions of the vessels (if any). A list available berths and free fenders can also be displayed. If there are no standard positions then the graphic display (VB 6) initiated. Once the standard position has been determined, the relevant data for berthing can be displayed on the View form, which can also be printed out.
A more detailed guide to this can be found in the user manual (Appendix B).
The output queries of the Forms give a list of any standard positions available for a particular vessel. A list of berths with available fenders can also be requested.
From the recommendations of the previous project, to use a bitmap for the vessel drawing would have been too slow and required too much storage space. Subsequently it was decided to use vector graphics for speed and minimum storage space.
One further aspect to be considered was how to zoom to the required scale whereby the vessels can be berthed. When reviewing the zooming functions available the question ‘how does the zoom function on a computer application relate to the zoom on a photographic lens’ was asked The answer is, it doesn’t.
On a bitmap application, the zoom function can do two types of zoom. One, on Paint and Paintshop, the zoom function increases the size of the pixels such that the pixels appear to be the size of square bricks. This is useful in computer imaging and enhancement techniques such as pixel aggregates used in forensics and photo identification. Two, such as on MSWord, the image is multiplied by a number of pixels, such that a line of one pixel thickness is now two.
On a vector map the magnification retains the same thickness of lines and can be truly said to be an accurate enhancement of a particular area of the image. An example of this would be a circle where a magnification of a particular section would retain the same width of the line.
However, all these methods of zoom functions will not increase the resolution or detail in the same way as the magnifying effect of a lens. It is in effect the same result as a photograph already taken, all the image data is already there. An exception to this might appear to be fractal images, where a section of a bitmap is expanded with increased resolution. This is not quite the same since a set of algorithms calculate the new image, sometimes after an appreciable amount of time, so in effect this is another bitmap at a higher resolution.
How then can graphical zooming methods work within the context of the project. The answer lies in mapping techniques used in cartography. As in maps such as the Mercator standard projections, the smaller scale map is a different map at an increased resolution. So in effect it is really starting at the bottom with small scale maps such as the Ordinance Survey Maps and navigational maps used in offshore navigation.
The larger scale maps are then a simplified group of small scale maps at less resolution. So to ‘zoom in’ from a large scale area on a bitmap the appropriate small scale bitmap would be called up. With this in mind it was decided to concentrate on the small scale berths (approx. 1/500), and use a “bottom up” approach
Fig9 Output Berth Design
A problem developed in installing Visual Basic 6 (Professional Edition). While the application was eventually installed, this process was time consuming and also required a major reorganisation of the hard drive resulting in additional drives being created in DoubleSpace mode to free the required space for the VB6 application. A prerequisite for installing VB6 was installing at least the fourth version of Internet Explorer.
Once VB6 was successfully installed it was found necessary to review the kind of graphical result required. The primary function of the mapping tool was to berth the vessels at least to one foot, and in some cases to within 6 inches on vessels of 1000 ft. (the QE2). How to achieve this level of accuracy for vessels of these dimensions on a computer screen required an analysis of how graphics are actually designed and their practical applications.
Now that the vector mapping approach was decided on, it was attempted to determine the best graphic tools either from the Visual Basic application or other means. Visual Basic has pre-defined graphic tools such as lines and a limited range of shapes. However, the API functions contain two main tools which are of interest. These are the polyline and polygon. The polyline is a line which can have any number of points, unlike the VB Line which has only a start and end-point. The polygon, as the name implies, can be any polygonal shape, ideal for the basic stick-model shape of the vessels.
The reasons for choosing the API graphic functions over the in-house VB graphics is twofold; one, API graph functions were tested to be five to eight faster than VB functions (Stephens 1997); but more importantly they are Windows functions and hence compatible with any Windows equipped PC, regardless of the application calling them.
The next stage was to determine the best measuring techniques, is it best to use an absolute scale method, or a model of the berths. Would pixels or points be used or something else? One of the drawbacks of using pixels for measurement is that different PC’s might have different screen resolutions set, i.e. 640x480, 800x600 etc. This means that the image will not appear the same size on the screens.
Background research revealed the existence of a Windows tool known as twips. These are extensively used in graphics such as games programs and other Windows applications since they enable any object to be the same size relative to any screen resolution. As quoted, they are screen-independent and approximately 1/1440 of an inch. This would appear to be a useful tool for measurement on an absolute scale.
However, a closer examination revealed certain ambiguities. When the screen resolution was changed (in Windows), the windows appeared very small and certainly not in proportion to the screen. It was found that the use of twips for windows only works if the same logical inch is the same for different resolutions. This is because twips are based on the number of pixels per logical inch. A logical inch is a virtual inch set according to a font display size.
What this means is that twips are a scaling factor of actual pixels, for instance, on a 640x480 screen with a logical inch set at 1.6 real inches there are 20 twips per pixel. On a 800x600 screen there are 15. So if the logical inch is set equally on all screens then the size of objects remain the same.
There are two objections to this when using twips as a measurement. On an absolute scale it cannot be certain that the fonts size (logical inch) has not been changed. The baseline font setting varies from PC to PC. On a ‘model ‘ scale when twips are used as a numerical counter, then the number of twips per pixel still changes even with the logical inch being the same length.
In order to calibrate the logical inch to a real inch it is recommended to place an inch ruler against the screen and slide the logical inch along to match the real inch (Windows Help 1995).
To even contemplate using such means to berth vessels of 1000 ft. to within at least one foot is careless in the extreme. It is found that far from being independent twips are doubly dependent, firstly as a measure of twips per pixel per logical inch, and also on the manufacturer settings for the base screen display logical inches which vary from PC to PC and cannot be changed.
What has been done then is to use Occam’s Razor and implement the simplest solution, that is using individual pixels as a model to represent one foot. The screen size may vary but the proportional model of the vessel to the berth will remain the same regardless of screen size or any other factors. A simple diagram (Fig 9) illustrates the output of the Visual Basic display. The vessel is drawn automatically by input from the Vessel table. The vessel is then moved by clicking on the forward or back buttons, while the numbers in the boxes change accordingly. A detailed guide is found in Appendix B.
The method of measurement is relative to the positions of the bollards. When examining which means to measure the position of the vessel against, it was found that the bollards, which are used by the berthing officers, will be most appropriate since they are quit literally set in stone and again also model reality. The bollard positions are taken from the bollard table.
Also since the berthing officers use a linear method to determine position, regardless of the geographical orientation, this method was also used due to the limitation of the graphics. In this respect if an angular orientation is used then some of the accuracy would be lost.
A demonstration of the software (database and graphics) was given at the VTS centre, Port of Southampton on the 19th December 2000. Present were Ms Kate Viscardi and Dr John Yates. From the Port were Mr Alex McKechnie, Berthing Officer; Mr John Kidman, Senior Berthing Officer and Mr Will Heaps, Senior Hydrographer.
A presentation was also to have been made, but with other management members absent it was felt a demonstration was sufficient. The software was successfully demonstrated to the satisfaction of all concerned. John Kidman enquired if a minor modification could be made to the vessel drawing- this was confirmed.
The result has been to develop a Berthing Tool that comprises:
The above software was also successfully demonstrated to the berthing officers.
The result of the technical approach was ultimately successful. The emphasis was on the practical “how-to” aspects and concentrated primarily on technical problems and their solution. The end result was to create a database that reflects the present system and to create a graphic method that fulfilled the requirements and can be used as a basis for further graphical functionality.
However, the software is still in the implementation and testing stage, with further evolutionary development still to come. The emphasis of this project has been to focus on the primary functions, and by so doing to enable further development on a sound foundation.
The database can be used independently of the graphics, enabling the berthing officers to complete ninety per cent of their tasks. It can also operate independently of PAVIS, if the vessels are all stored in the database. The graphics program does not hold any data, but implements the input from the database in graphical form.
Since this is an evolutionary development model the software has been tested but the debugging is still to be initiated. On the waterfall model the software at most reached the implementation and unit testing stage.
It has also been found that much of software strategies and methodologies need to be re-examined in the light of certain types of scripting applications and how they relate to real-life scenarios. The solutions found would not have been possible using applications packages and their techniques.
The results of this project have been successful insofar as this is the Alpha version, that is, a demonstration of the feasibility of the software. A number of factors that influenced the methods used have been found, not least of which was the requirement to use lateral thinking regarding measurements and zooming functions.
Due to the complex nature of this project the requirements and the necessary output were not as straightforward as first appeared. While the database was comparatively straightforward, the graphics involved demonstrated the weakness and rigidity of standard application packages such as Visual Basic.
Most of the work and strategies involved were not taken from background references, with the exception of the requirements analysis. Rather the resulting methods and ideas were derived empirically in addition to previous experience.
Re-examining the previous projects results it was found there would have been more problems encountered since the approach did not take into account the engineering aspects, nor was there any method of exact measurement indicated. This is not a reflection on the previous project students but rather an indictment of the IT strategy in the “real world”.
The database design may be thought of as a “top-down” method, while the graphics were very much a “bottom-up” approach (Rumbaugh 1992). Difficulties were encountered when writing the Visual Basic code since the unorthodox methods were not readily compatible with the standard strategy of writing Visual Basic or indeed any application using a top-down scripting approach.
Also it was found that what can be described as an “applications-oriented” methodology to be prevalent in general thinking and organisation of virtually most IT consultancies and software houses or departments. The limitations of conventional applications, while usually apparent in fields such as engineering, are not noticeable in more general software fields where the applications involved are usually sufficient for the task in hand. Many of the so-called “bespoke “ systems are generally a variation of standard packages where the tailored requirement is nothing more than a few changes in form design.
The use of twips in the MS Windows environment is a useful tool if, and only if, this method is only used for Windows and games. The information concerning the use of twips was at best misleading and at worst highly dangerous to use in a real-life application.
A Visual Basic “expert” was also consulted regarding communication between different Microsoft applications in addition to using API functions in a VB environment. Sad to say, no useful information was found.
In designing the software a common sense approach was used, which may be likened to a civil engineering example. This is the house building scenario where the house is first built by laying the foundation, then the load bearing structure, and finally the walls, windows and doors. Conventional applications using Windows and forms are pre-structured to a large degree, and the solution favoured by developers is to use a “clicky mouse” system as it is known in the trade.
Two of the previous project’s functional requirements, the time element and the security aspects need to be considered here for further development. The time element can be added by a change in table design and should be implemented in the final design. The security needs also should be developed. Note may be taken here of one of the considerations of requirements analysis, that of prioritisation. In order of priority for the requirements of this project the above two functional requirements may be left till last, especially the security function.
To use the “house” analogy, security such as locks etc. are put in place after everything else has been completed. There are some projects in which security aspects are an integral part, but as this project is not involved in building the Pentagon or implementing a Strategic Defence Initiative this can quite reasonably be left till last.
One of the advantages found was that the customers, that is, the berthing officers, were aware of what exactly what was required. The usual case is that customers are not aware of what is required, so developers have a tendency to produce what they feel is best for the customer. An example of this is the PAVIS system which was developed at a great cost, but from having spoken to some of the users, for example the pilots, the output falls short of requirements.
Other than “re-inventing the wheel” as it were by returning to non-visual programming this is something that will have to be lived with. However, with a little original thought and initiative it is still possible to achieve a result, although perhaps not in quite the same manner as expected.
The following recommendations are advised:
1. Reehal H S BEng (Hons) Project Unit Guide School of Electrical, Electronic & Information Engineering, South Bank University, London (2000-2001).
2. Meredith J R and Mantel S J, Project Planning – a Managerial Approach, Third Edition, John Wiley and Sons, New York, (1995).
3. Sommerville I, Software Engineering, Fifth Edition, Addison Wesley (1995).
4. Tavner J & Mueller P (Editors), Southampton Port Handbook, Land & Marine Publications Ltd. (1998).
5. Abdelrahman N, the Design and Implementation of a Graphical mapping Tool, MSc Project Report, SEEIE (1999).
6. Potts S, Visual Basic 4 Expert Solutions, First Edition, Que Corporation (1995).
7. Mansfield R, Visual Basic 4 Power Toolkit, First Edition, Ventam (1995).
8. Gurewich N, Teach Yourself Visual Basic 4, Third Edition, Sams (1995).
The initial project plan was expected to review databases and graphics packages and to develop a software system. However it was found that standard graphics packages were inadequate for the task and additional research was necessary to find alternate methods.
Additional alternate methods not expected in the original plan were examined and implemented. The model became one of evolutionary development, hence debugging, except in a limited sense, was not a factor since the software is still at an early stage of development. The final Gantt chart reflects the revised plan (Meredith & Mantel 1995).