CAD-Centric, Multi-Source Data and Information Management
Nick Danese, Nick Danese Applied Research, Antibes/France, ndar@ndar.com
The ability to share data during ship design, production and management is very limited, with undesirable consequences. Data that could be shared with benefit can be loosely categorized as CAD and non-CAD, as a function of source, nature, but also practical use and possible exploitation parameters during the various stages of the ship’s life span. Existing off-the-shelf tools and technology can be used today to share, manage and exploit such data. Examples of the above, including software recently developed for the purpose will be illustrated, and a practical example presented.
1. Introduction
The effective use of orally transmitted data has been the foundation of mankind’s evolution, Danese (2010), but for practical and effective use in modern industry data needs to be re-usable exactly. At least three corollaries follow:
– data must be stored persistently.
– data must be retrievable.
Therefore:
– data must be stored electronically.
Then, the creation of an electronic version of data is the first step. Electronic storage being a rather non-standard environment by definition, data must be formatted intelligibly, and formatting must be documented. While being obvious, this is the case far less often than desirable. The vast number of electronic data organizer tools developed in recent times is a loud symptom of the importance of data management, and the absence of one, or even a few, standard-setting product(s) an even more evident
indication data-sharing proficiency has not been achieved.
The reason for data not being shared effectively is not fundamentally technical, plenty of tools exist today to help find, retrieve and process information. On the other hand, assuming that data has been made available in the first place, which is more and more the case, how it is made available will determine whether it can be found or not, and then exploited, or not.
With regards to the CAD environment, and more specifically the ship related industry, a majority of data does exist in electronic form, is readily available in industry standard file formats, but is not exploitable for a number of reasons, two immediately identifiable culprits being proprietary data structure, and absence of contextualization.
2. Common place data management tools.
Among the remarkable efforts undertaken so far, some are representative of the main avenues of development: MS-SharePoint, the web search engine (Google, Yahoo, etc.) and social networking systems (FaceBook, etc.). However:
– MS-SharePoint manages documents of various nature, but not necessarily the data contained in them.
– Search engines like Google, Yahoo, etc. use keywords, which can be loosely compared to a relational database structure, and successive searches, but are somewhat limited to formatted text and, for example, do not read inside databases, files, etc.
– Social networking systems are designed to allow multiple sources to contribute to a given data set, “friends” are allowed to post to an individual’s page, but again data is exposed through text.
Perhaps cynically, but it could be argued that the difference between the above and the eternal (and ubiquitous) card filing systems is “limited” to the global reach of the formers, and the filing cabinet bound nature of the latter.
3. CAD and non-CAD data
In a first, perhaps somewhat simplified approach, two generic data groups will be identified, CAD and non-CAD. CAD data is loosely intended to include all data that can and is explicitly generated and represented by “graphical” means, such as a line, a solid, etc. This data is generally created by CAD programs, or via graphical libraries (ex. Hoops, etc.). non-CAD data includes all data that is difficult
to or cannot be represented by graphical means, such as relations between objects, number of objects, results of calculations, dates, etc. Nonetheless, this data can be and often is, an integral part of the message to be delivered in conjunction with or even by CAD data.
The word “graphical” undeniably lends itself to argument, so let us consider a debatable example: the concept of thickness. Thickness can be represented graphically, generally by hatching a section or of two parallel segments, but its value is generally expressed with a number, written as such.
4. Data structure, contextualization and inconsistency
Further to previous work on the nature of data and more specifically ship-related data, Danese (2010), a high-level study of data structure and contextualization was undertaken, taking into account the implications of the intrinsic inconsistency of data.
4.1. Data structure.
By data structure it is meant how the data is stored and, hence, made available. Data structure will depend on the nature of the data (somewhat universal), and on how the data will be interpreted in order to process and present it.
4.1.1. Data structure of CAD data.
Let us consider different ways to describe a line segment and a cylinder, but in each case using the same data set (one data set for the line and one for the cylinder).
This examples applies equally to lines and cylinders created via the graphical interface of a CAD program, via the programming of a graphical library, or via the use of neutral file formats, such as Autodesk’s DXF. So, while the information needed to identify the line and the cylinder is always present in an explicit format, unless the structure of the format is known the data cannot be used.
4.1.2. Data structure of non-CAD data
Let us now consider a table of numbers, from which we wish to retrieve totals. Interestingly, such a table could be created using a CAD program or a graphical library, but in this case the numbers would not be treated as such unless the software is capable of managing and processing logical information, which is not always the case. The contents of the tables are the same (the individual numbers), but the totals will depend on the direction of summation (by row, by column, diagonally, etc.). Therefore, while containing the same data, the two tables shown hereafter will have to be interpreted differently.
In the first case the summation will be conducted by column, in the second case the summation will be conducted by row:
For a slightly more abstract example, let us consider a common planning situation, such as the need to identify which parts of the ship are scheduled for assembly on a certain date, and to cross check the availability of a hired crane of sufficient lifting capacity to move the finished assembled to another location in the yard.
While the ship parts can be represented graphically, and even the crane for that matter, cross-checking assembly completion date and crane availability probably cannot.
To go one step further, let us consider the case of the crane becoming unavailable at the last minute, for example due to a mechanical failure, and the ensuing consequences due to the fact that the assembly hall remains unnecessarily occupied by the completed assembly.
Once again, CAD data (which parts of the ship will be affected) and non-CAD data (the planning corrective measures to be taken) are related and inter-dependent, and it will be beneficial for both data types to be documented in an exploitable fashion and be available together.
4.2. Data contextualization
For the purpose of this work, data contextualization is intended as the intrinsic meaning of the data itself. For example, a line could represent another object altogether, such as a stiffener, and a number could represent a weight or a frequency, etc..
The intrinsic meaning of data creates and controls the need for data to be available, found and interpreted in a given context. For example, weight data is relevant in the context of weight reporting but, more to the point, the context itself will drive the use of that data. For example, consider the need to either know the weight of an object or the total weight of a group of objects. In the first case we are dealing with direct data reporting, while in the latter we are dealing with data processing at first, and then data reporting. Going further, the total weight of one type of object might have to be multiplied by a unit cost, while the total weight of another group of object will be multiplied by a different unit cost. So, contextualization extends beyond the initial data itself, to the realm of data processing.
Data contextualization is generally achieved by the use of words, such as titles, descriptions, etc., which works well in the case of a printed document, but less so in the case of electronic data storage and transferring. Other, but simpler and more limited ways to contextualize data is to use colours, layers, file names, etc.
Structuring and formatting is a pre-requisite to the contextualization of electronic data, and that effective use of contextualization more often than not requires handling of the data itself, as opposed to access to data storage itself. For example, the title of a drawing or of a file may indicate the presence of certain data, but will not directly supply the data itself, which must be searched for, retrieved, interpreted and possibly processed.
4.2.1. Contextualization of CAD data
Going back to the example of the line and the cylinder, here are a few different possible meanings for these graphical entities:
4.2.2. Contextualization of non-CAD data
non-CAD data is perhaps even more in need of contextualization. To use the tables of numbers example again, although the two tables contain the same numbers, each table may refer to different quantities, such as weight and thickness. Moreover, each number itself may represent something different.
Then, data structuring must be developed to the level of detail required to correctly contextualize each piece of data.
4.3. Data inconsistency
While other words may be semantically more fitting than “inconsistency”, its general meaning accurately represents the practical problem presented by the need to associate data of the same type, but in different groups and to different extents. The theory of ensembles is a simple way to illustrate the above:
So, the practical task is to structure data in such a way that CAD and non-CAD data can be associated in any desired manner. For example, a line representing a stiffener may have a colour, the stiffener may have a different colour, and the planned date of assembly of that stiffener will not have a colour assigned to it at all. Yet, line, stiffener and date are associated. What is more, the colour themselves may be described differently, such as by name, by number, by pantone codes, by rgb percentages, etc.
So, managing data inconsistency requires the documentation of relations and associations.
One effective way to stipulate associations is the use of relational data sets. Relational data sets are thereby contextualized to the deepest level, as required to associate the individual data elements. This can be achieved by using potentially large numbers of files and a management software to link the data in the files, or by using relational databases.
5. Databases
Using files and corresponding management software does not only not have unique, outstanding advantages, but also carries the potentially disastrous disadvantage of the data not being collected in a single repository, which makes it very vulnerable to damage and loss, and difficult, if not impossible to share and to associate with data from other sources. Relational databases, such as SQL, can be as immediately human-readable as plain text files, and additionally offer several significant advantages:
– the data is collected in one container (the database file)
– scripts, queries and procedures provide a rational way to store, retrieve, pre- and post- process data, and insulate the data from the user thereof
– data integrity is protected
– the database engine automatically manages concurrent access to same data by multiple users
– association of data belonging to different databases is a feature by design
– the amount of data that can be contained in a single database and the number of associations are virtually unlimited
Moreover, reviewing ship data models, databases and associated CAD files, if any, tend to occupy 2.5 times less data storage space than file-only systems, on average. The author having direct experience mostly with the ShipConstructor database, this has been used in the research and development work presented hereafter.
6. The information model
A detailed review of the ship data model is presented in Danese (2010) and, in terms of data contents, can be summarized by the following flowchart:
Differently than most if not all other ship data systems, it should be noted that the flowchart shows data flowing back into ShipConstructor’s database. In other words, any non-CAD data directly related to any “object” in the ShipConstructor model can, and should be stored in the ShipConstructor database. Two crucial comments are in order here:
– “objects” in the ShipConstructor database are not limited to graphical and physical objects, such as lines or solids, but include logical entities, such as a branch in any of the user-defined hierarchical model structures, or a stock.
– the ability to collect and most importantly associate CAD and non-CAD data is the sine-quanon criteria which must be satisfied in order to qualify a true data and information model as such. In fact, it becomes appropriate at this point to use the information model label in its full right, as the “data” connotation is, by definition, an underlying pre-requisite.
Moreover, it becomes evident that such an information model is no longer limited to the ship per-se, but involves and affects other, much far-ranging domains, such as company management, extra-ship PLM, etc. One final note, yet fundamental to the considerations above, is that data can also flow from the ShipConstructor database to any other data repository, as the need may be. Therefore, the conditions to define an information model can be resumed to:
– it must be possible to associate CAD and non-CAD data, from different sources
– it must be possible to import data from and export data to other concerned software systems
7. The ShipConstructor information model: macroscopic structure and data flow
Macroscopically, the ShipConstructor information model is based on a single SQL database and on AutoCAD files. Data is exchanged and synchronised between the SQL database and the AutoCAd files via a direct, real-time, transparent interface. Moreover, data can be input from both inside and outside the ShipConstructor environment, via AutoCAD and via SQL.
7.1. Macroscopic structure
In short, the AutoCAD file contains a copy of every ShipConstructor object created in it (lines, solids, relations, associations, etc.), while the SQL database contains all ShipConstructor objects created either in AutoCAD files or directly via the graphical SQL database manager, all the libraries of objects, relations, associations, etc. and the environment settings. This combination, and in some instances the managed duplication, of CAD and non-CAD data is fundamental to the achievement and exploitation of the multi-source input/output data flow described here after.
7.2. Data flow
While the words import and export describe well the flow of data, these terms generally refer to the use of intermediate, data exchange files. In the case of ShipConstructor, while classic import and export are supported, the tools available to exploit the data contained in ShipConstructor information model actually allow data synchronization, provided of course that other software involved in the process does, too.
Data flow is described in some detail in the following paragraphs, but one aspect thereof deserves foremost mentioning, and that is the purposely built-in by-design ability to interact with the ShipConstructor information model using commercial off-the shelf shrink-wrapped tools, be they software in its own right (ex. Crystal Reports, Oracle/SQL interfacing software, MS-Office, etc.), or programming tools (ex. C#, VB, Lisp, etc.).
This is possible thanks to several features offered by the ShipConstructor environment, such as:
– an increasing number of ShipConstructor commands in the AutoCAD environment are exposed and can be scripted.
– database interaction is made virtually transparent thanks to the ShipConstructor API, stored procedures, and exposed queries.
– access to raw data is permitted (but not encouraged)
– user-defined tables may be added to the ShipConstructor SQL database
– the ShipConstructor SQL database may be linked to other databases
– last and perhaps most powerful, the ability to interact with the ShipConstructor information model in a remote, IT neutral fashion, using standard communications technology
Much work has already been carried out exploiting the facilities described above, and a few examples
are presented in a later chapter.
7.2.1. Data input
In terms of data creation, several mechanisms are available in the ShipConstructor environment:
– CAD input, via the AutoCAD environment, using AutoCAD commands, ShipConstructor functions and non-ShipConstructor functions and programs.
– non-CAD input, via the dedicated ShipConstructor graphical interface through which the SQL database is managed, and via non-ShipConstructor functions and programs.
It is very important to note that reference is made here to “input”, as opposed to “data”. The distinction is fundamental, and it is made because the ShipConstructor user will create and provide both CAD and non-CAD data via both input facilities: the AutoCAD environment and the SQL environment. So, graphical entities, modelling schemas, parameters, associations, etc. will be defined in some instances via the CAD AutoCAD environment, and in other instances via the non-CAD SQL database environment. A special note is in order at this point to underline the importance of CAD and non-CAD data associating mechanism, specifically using input from multiple sources. The core mechanism offered by ShipConstructor is the User Defined Attribute (UDA). The ShipConstructor UDA is a particularly powerful and versatile tool in this respect, because:
– UDA data can be input from both inside and outside the ShipConstructor environment
– UDA data can be virtually anything: numbers, strings, hyperlinks, etc., and the range grows as need demands, to formulas, etc.
7.2.2. Data output
A large number of options are available to create output, but a concise summary of output “types” will serve the purpose of this study:
– graphical (ex. paper drawings, pictures, etc.)
– tabular (ex. reports)
– to neutral file formats (ex. dxf, pdf, dwf, rtf, etc.)
– to proprietary file formats (ex. MS-Excel, NavisWorks, etc.)
– via off-the-shelf software (ex. Crystal Reports, MS-Office, etc.)
– via custom applications (ex. goal-specific harvesting from the AutoCAD and SQL environments)
One very important note with respect to output, is that data and information can be extracted from theShipConstructor environment without need for AutoCAD and/or ShipConstructor. Only access to the database is required. This is important because the contents of the ShipConstructor information model become available to virtually anyone at any time, and more particularly they transparently become a dynamic component of company management, tactical and strategic decision making.
8. Development examples
First of all, the author is not a proficient programmer, and hence credit must be given to those who carried out the coding behind the tools and applications illustrated here. The few examples illustrated here have been chosen to cover a variety of possible contexts:
– CAD environment: custom labelling of ShipConstructor parts.
– SQL environment: custom reports of ShipConstructor data.
– combination CAD / database environment: combining CAD and non-CAD ShipConstructor data into User Defined Attributes to embed custom Product Hierarchy information into a standard ShipConstructor Bill of Materials table (BOM).
– SQL environment: external input from a non-ShipConstructor source.
– SQL environment: combining data from two ShipConstructor databases, then further processing it.
– SQL environment: automating the acquisition of planning and scheduling information from third party suppliers using wireless technology (GSM, GPS and RFID)
– exploitation of the open ShipConstructor Information environment in the early phases of estimation
8.1. CAD environment application: Custom labelling of ShipConstructor parts
Custom labelling was developed to accommodate specific drawing detailing and presentation requirements. Custom labelling is effectively an AutoCAD application, and uses data contained in the AutoCAD file. The custom labelling example shown here directly harvests data from the ShipConstructor objects present in the AutoCAD file current in the AutoCAD session (as opposed to a referenced file), and uses the harvested data to create formatted, persistent text strings (the parts’ labels) in the same AutoCAD file. The labels are then stored in the file, and printed along with the other AutoCAD and ShipConstructor objects contained in that file. Fig.6 shows one possible code set to be used to interrogate the ShipConstructor parts and harvest the data:
8.2. SQL environment: custom reports of ShipConstructor data
Custom reporting was developed to accommodate specific report formatting and content requirements in a single report, and more specifically:
– custom-defined part count (quantities).
– custom-defined grouping of parts in the report table.
– reporting of user-selected part properties, including properties embedded in the part object as no-process text.
Custom reporting is written in Crystal Reports, and only requires access to the SQL database. No access is required to AutoCAD and / or ShipConstructor. For reference, it will be helpful to describe the structure of a ShipConstructor part. In short, a part is composed dynamically from a collection of associated information which includes CAD data (geometry, text, et.) and non-CAD data (attributes, properties, associations, parameters, User Defined Attributes, etc.). Therefore, Custom reports are generated by harvesting data from the ShipConstructor database, and arranging into a custom-formatted disposing report sheet, as follows:
– in the ShipConstructor database find the parts required by the user
– harvest the parts’ information and collect it in a matrix
– create a table using the desired part information
The following example shows one possible code set to be used to interrogate the ShipConstructor database and harvest the required data:
8.3. Combination CAD / database environment: combining CAD and non-CAD ShipConstructor data into User Defined Attributes to embed custom Product Hierarchy information into a standard ShipConstructor Bill of Materials table (BOM)
This application exploits the flexible nature of User Defined Attributes (UDA) to create and document a custom-defined, post-processing hierarchical sequence. The post-processing sequence is described in a verbose fashion and, in this case, uses the names of Product Hierarchy branches according to the company’s specific production strategy. The post-processing sequence is documented in the Nest Drawing, by embedding the desired UDAs into the user-defined ShipConstructor Bill of Materials table (BOM) – in ShipConstructor, the user defines the BOM to his requirements using keywords that give access to virtually all the data contained in the database. It is used by the NC-machine operator to sort the cut parts according to each part’s defined post-processing sequence. This a mixed AutoCAD / ShipConstructor application, in that it uses both data contained in the AutoCAD file and data contained in the ShipConstuctor database. The application works as follows:
– interrogate the parts present in the Nest file (AutoCAD environment)
– then, from the SQL database, harvest the Production Hierarchy structure starting at the individual part’s level, then upstream (read from the database)
– for each part, populate the corresponding UDAs in the database (write to the database)
The following examples shows possible code sets to be used to interrogate the ShipConstructor Nest file and to harvest the required data from the database, and to populate the UDAs by writing to the database.
8.4. SQL environment: external input from a non-ShipConstructor source.
The example described here is a small part of a much larger ShipConstructor-assisted company management environment. Its peculiarity is that its functionality is available through any html compatible environment, irrespective of operating system or device brand. For lack of a proper name, it is referred to as RDM (remote data management).
The goal is to “de-materialize” access to and management of selected ShipConstructor data contained in the SQL database, under the MS-Windows OS. Of course not all data should be modifiable from the outside, and not everyone should have access to all data. The ShipConstructor database is accessed via IIS services, which are a standard part of the Windows OS distribution and installation. This is achieved very simply by a password controlled log-on, which also allows to dynamically create a user-specific graphical interfaces, tailored to cater to the user’s requirements, subject to his permission clearance. While programmatically rather complex, the application is very simple in concept, and works as follows:
– from any html compatible device connected to the internet or to a LAN/WAN network, the user connects to the IP address of the PC hosting the RDM application
– the RDM sends the log-on html GUI to the device
– the user logs-on with name and password
– the RDM sends the user-specific GUI to the device
– the user operates using keyboard, mouse, touch-screens, etc.
While much of the source code is proprietary and is not presented in this document, read and write access examples to the ShipConstructor database are described herein.
The application has been tested successfully using the following devices: PC (various versions of Windows and web browsers), BlackBerry, Android mobile phones, IPhone, etc.
8.5. SQL environment: Combining & processing data from two ShipConstructor databases
Custom reports can be as simple as specially formatted tables, or as complex as full data processing engines involving data from different sources. In addition, with reference to other examples in this document, the results of data processing can be in turn written back to the desired database(s), for example by populating a UDA. Custom reports are based on data harvesting, and subsequent data processing With reference to the examples already presented in this document, the Crystal Reports document illustrated below harvests data from two ShipConstructor databases and processes it into a combined result. As mentioned in the discussion of input and output option elsewhere in this document, the result can the then be included back into a ShipConstructor database, for example by populating a UDA field.
8.6. Exploitation of the open ShipConstructor Information environment in the early phases of estimation
The following information flow schema was developed to exploit the open ShipConstructor Information environment already from the early phases of estimation. The schema is presented succinctly, and reference is made to the information presented herein so far.
8.6.1. The ShipConstructor information environment comprises (recap)
– 2D AutoCAD drawings, used for 3D model input and output. It is a familiar, configurable environment, and, contains both ShipConstructor and non-ShipConstructor data.
– 3D realistic, solid model: attribute and property rich. Properties include CAD and non-CAD data. Model is fully integrated and mutli-discipline, gives overall geometrical and non-geometry data.
– SQL database: offers export and supports external harvesting of data, reports include user-selected data in user-defined formats, export facilities, etc.
8.6.2. Estimation using the single model approach, extensible to design and production
This approach consist in modelling a scalable, representative Unit in detail, and the rest of the ship macroscopically (scalable primary structure such as main frames, bulkheads, decks, etc., representative secondary structure, primary and large schedule distributed systems, etc.). This data is then used raw as-is or further processed:
– as qualitative input to create or validate preliminary scheduling and planning, for example in MS Project.
– feed preliminary purchasing estimation, for example in SAP, which in turn will influence the preliminary planning and scheduling
The CAD portion of the data is computed automatically and stored as object properties, such as weights, number of plates to cut, lengths of weld, etc. The non-CAD portion of the data will include user defined processing entities, such as blasting grit grade, paint and finish specifications, assembly sequence, etc., and user specific parameters such manufacturing hours as a function of yard resources and task complexity, etc. non-CAD data is yard specific, user supplied and added to the model via object properties and User Defined Attributes.
Information-model dependent reports include the relevant data from the SQL database, sorted and grouped according to the user’s requirements, either using the ShipConstructor reports engine, or other software, like Crystal Reports. Data is further processed as required to obtain the relevant quantities for use in management, tactical and strategic decision making. Raw and processed data is thus available for immediate use, as direct input for building an MS-Project Gantt chart or for further processing by ERP/MRP software, such as SAP.
Other non-CAD information also influences the planning (availability of materials and resources, other objective constraints), and the structure of the ShipConstructor Information model. For example, a given availability of steel may influence the planned assembly sequence.
8.6.3. Integration of planning, cost analysis and model
One or more iterations may be needed to synchronise the model (choice of yard processing and build sequence, modelling schedule to produce required data, etc.) and the overall planning, also with respect to cost and other objective constraints. Estimated and projected data are input back into the model (ex. model “by” dates, nest “by” dates, names of assigned operators, revised processing information such as finish, etc.), principally in UDAs associated with model parts and non-CAD objects (ex. the projected elapsed time needed to complete the assembly of a branch of a Product Hierarchy based on available resources at that time during the planning and on objective difficulty and complexity factors, and the corresponding cost). As the information is now collected and managed by several connected tools, it becomes appropriate to use the Information Model definition, the ShipConstructor Information Model being part thereof. As cross-feed back balances out, the Estimation model can be considered achieved.
From this point on, data flow is managed at least multi-directionally between ShipConstructor, planning/scheduling software (ex. MS Project), ERP/MRP software (ex. MARS) and management software (ex. SAP), but perhaps also to/from other data sources (ex. a subcontractor suffers a set-back, or a strike forces re-tasking and re-scheduling, or bad weather delays painting, or the price of a sourced item drops thereby allowing its purchase and its fitting sooner, etc.).
Throughout the process, the interface between information and management (who are not often proficient in CAD and other discipline specific software) is achieved without the direct use of any of the programs generating the raw data (ShipConstructor, AutoCAD, SAP, etc.), but rather via graphical collaborative reviewing software (ex. Autodesk’s NavisWorks) and dynamic reporting software (ex. Crystal Reports).
8.7. SQL environment: automating the acquisition of planning and scheduling information from third party suppliers using wireless technology (GSM, GPS and RFID)
The ability to write information to the ShipCostructor database opens innumerable doors to catering to many management requirements. The example presented here is based on a rather common circumstance, the geographical distance between a cutting company and the shipyard(s) where those parts will be assembled. In fact, the geographical distance often entails crossing of borders varying transport regulations, perhaps vastly different meteorological conditions, traffic jams, etc. Therefore, real-time knowledge of the location of a truck transporting cut parts is of great interest. While geolocalization has become common place technology, it was sought to make available relevant information about the cargo being carried in an operator-less fashion.
Therefore, programmable active/passive RFID technology was added to existing GPS/GSM geo-localization. In short, the planned system, based on current off-the-shelf technology and hardware, will works as follows:
– upon loading of cut parts on a pallet or flat rack, an RFID tag attached to the pallet or to the flat rack is programmed with a tracking number and the list of parts (obtained from the NC-cutting file or other ShipConstructor supplied information).
– upon leaving the premises, the tag connects with the active transponder of the RFID system, and the following information is sent to the Information Model via GSM: pallet / rack tracking number, list of parts.
– at pre-set time intervals, the geo-localisation portion of the tag signals its GPS position, which is fed to the Information model.
– finally, upon entry of the shipyard’s grounds, another active transponder reads the tag’s contents and feeds the arrival data to the Information model
Incidentally, it is interesting to note that when produced in small quantities the cost of the tag and of the corresponding active RFID transponder described above have been estimated as negligible at the scale of the ship industry.
9. Conclusion
The use of off-the-shelf technology and tools to compose and exploit a true Information Model has been documented and advocated before, Danese (2010). The few examples of completed and on-going development work discussed here represent only a small cross section of what has already been achieved, and are aimed at documenting the ease and simplicity of building the basic bricks of an Information Model, a goal within just about everyone’s reach. Of course, requirements change as new tools become available, and vice-versa. However, the use of off-the-shelf software, hardware and technology greatly reduces the amount of resources to be expended in catering to change. This intrinsically scalable approach is then deemed viable.
Acknowledgement
A special thanks for supporting the author’s research work is owed to Pedro Antunes (Vera Navis, Portugal), Luis Batista (Vera Navis, Portugal), Stefano Cipriani (Nice RFID, France), Darren Larkins (ShipConstructor Software Inc., Canada), Deniz Morais (ShipConstructor Software Inc., Canada), Lambertus Oosterveen (Royal Huisman, The Netherlands), Justin Paquin (ShipConstructor Software Inc., Canada), Stefan Raev (Royal Huisman, The Netherlands), Peykan Sahelnia (PS Development,
France), Arkadiy Zagorskiy (Marine Technologies, Russia)
References
DANESE, N. (2010), Ship CAD systems – past, present and possible future, COMPIT, Gubbio, pp. 396-408