Getting Product Design Calculation Documents Onboard a Model Based Design, IoT and PLM Framework

Reefer Container and Ship information in Orbcomm VesselConnect (source: Orbcomm) https://dvzpv6x5302g1.cloudfront.net/AcuCustom/Sitename/DAM/087/Reefer-Connect3_Orbcomm_VesselConnect_IoT_Net_Feasa_affino.jpg

Introduction — Product Data in Desktop Documents

Numerous articles and discussions on various Engineering Forums have been on how and why many entities still rely on desktop documents for storing and transacting Product Data. Also, why there is a hesitancy when it comes to hitching onto the PLM bandwagon in the true sense fully. Probably it could be the difficult experiences in the past or cost considerations, or because of the nature of data itself, such as spreadsheet design calculations, simulation results, etc., which, anyway, has to be managed outside PLM. In the scenario, when fundamental product data is out of Databases, so are the benefits of easy data accessibility, process standardization, workflow, lifecycle, integrity, security, efficiency, efficiency, traceability, etc.

Now, with AI & ML technologies, including Computer Vision, NLP applications, IoT, and Cloud platforms, we face even more questions on how to effectively utilize these for tangible benefits. Again, the challenge is, when the basic Product Data are islands of information themselves, how are we going to assimilate these islands with the emerging technologies into a common source of truth. It is therefore apparent that the PLM hurdle needs to be cleared first.

A Framework for Desktop Data Migration

Many companies would have in place Product Information networks sufficiently managing all their product data including design calculations. This article brings out “a” way in which we can look to organize and migrate desktop data, specifically, design calculations which are mostly in spreadsheets, into a PLM connected Model Based Based Design and IoT framework. Whilst design calculations by themselves are only a part of the overall Product Data that resides in documents on varying percentages in entities, they are nevertheless crucial, and, important to be managed in a PLM system with all its features as mentioned above. This article is focused more on technical details of the framework, which can serve as a useful template for those desiring to move out of desktop documents towards Databases.

Model-Based Design applications are the starting point to structure the Product design calculations into Model Blocks as convenient, with the desired flow of information configured accordingly. It makes sense to also have IoT Platforms onboard with their extensive reach and connectivity to data in a physical environment, and, all of these integrated with the enhanced data management capabilities of PLM Systems. This could pave the way subsequently for the inclusion of areas such as in-service monitoring, predictive maintenance, and condition inspections, which, have relationships to the basic product parameters in the Model Design Blocks.

The Document Approach

We take a very basic calculation in Ship Design which is handled using desktop documents. There are spreadsheets for calculating the Ship Draught & Displacement and “Equipment No.” The latter is a factor generally used for selecting Ship Anchoring, Mooring & Towing Equipment. Users share required values of parameters and variables for these calculations through emails or shared folder files. Whenever there is a change to any parameter or variable, it is up to the Owner to manually update the others, or else there is a risk of incorrect computational results.

So, we can see how more and more spreadsheets can get involved in these calculations, which is only a minor part of the overall Ship Design process. For typical large and complex Automotive, Aerospace, or Shipbuilding products, such spreadsheets can run into thousands or more depending on product complexity. Moreover, many of these documents contain data tracked and monitored in the product lifecycle cycle, extending from a few years to decades. In short, not only will more human resources be consumed, but the possibility of errors may also be commensurate with the growing volume of document data.

Model Based Design Approach

We utilize Scilab, a desktop Model Based Design & mathematical simulation software, for performing the same Ship Design calculations mentioned above. Scilab has numerous inbuilt mathematical functions accessible through a high-level programming language for creating simulation models through a graphical editor, “XCOS.” The models are structured to be scalable through multiple “Blocks” of computation. The idea is to treat data in each desktop spreadsheet as a “Component Model” of the Product, as seen in Fig 1(a) & (b), with data exchanged between them as shown.

Fig. 1(a) “Main Particulars” Component Model for a Ship

Fig. 1(b) “Equipment No.” Component Model for a Ship

Fig. 2 shows the process flow within Scilab on a desktop, considered as a single Component Model. An input script runs in the command console, assigning values to various parameters and defining relationships between variables. After the XCOS Block modeling is complete, as described above, and the Simulation run, the output script is executed in the console for displaying results.

Fig. 2 Desktop Component Model Process Flow

Web APIs — The Data Communication & Transfer Engine

Scilab provides REST API Web Tools for sending (HTTP POST) and receiving data (HTTP GET) to and from various Cloud Platforms, Ubidots being one amongst them. Typically, the Ubidots can set “Devices” with “Properties” in the Cloud (or In-Premise) Account to match any Product Configuration with desired attributes. Fig. 3 shows a Ubidots Cloud Dashboard, with a Ship Product set as a Device. Each Device has preset variables such as, in this example, the main parameters length, breadth, block coefficient & variables such as depth, speed, displacement of the ship. Ubidots has an added advantage over some other similar IoT platforms in its capabilities for users to generate their own custom devices & variables.

Fig. 3 Ubidots Dashboard showing “Devices” and “Variables” connected with Aras & Scilab

The figure shows the current variable values in Ubidots received from Scilab. Having connected Scilab to an IoT Platform, we now look to connect PLM functionalities through Aras PLM, also seen in the figure.

Aras PLM also provides REST API for bi-directional data exchanges with Cloud Servers and other Server-based Applications. Aras plays the vital role of repository of all data in the framework and, therefore, connects to Ubidots, which becomes a source for Scilab to get its data for Simulation. Simulation results from Scilab sent back to Ubidots are then validated in Aras PLM Server against the predefined performance values. The main advantage of using Aras is that any Product modifications, which result in new or updated parameters, will be visible in the IoT Platform Ubidots and also available for the Component Models & Simulation in Scilab.

Integration of a PLM Database Application with an IoT Platform

Let’s have a closer look at how Aras integrates with Ubidots. In Aras, all Product Data are structured as “Item Types” depending on the functionality. Some of the Product properties in these Items are “federated,” i.e., set to view live data from external applications from within Aras. Minerva Group has provided a method to integrate Aras with JIRA, a proprietary issue tracking product developed by Atlassian that allows bug tracking and agile project management (Minerva PLM Blog: How to integrate JIRA into Aras Innovator https://minerva-plm.com/blog/posts-folder/2019/august/how-to-integrate-jira-into-aras-innovator/). Based on this method that utilizes REST API, an Aras Item has some of its properties federated from Ubidots as seen in Fig. 4. Thus, we can see that Ubidots platform can have values for the device parameters & variables received from both PLM System Aras and, as described earlier, Scilab. The Cloud Application Ubidots, thus, for large and complex products, can function as a central live dashboard which is very useful for monitoring & management.

Fig. 4 Aras Item search results with some properties “federated” from Ubidots IoT Platform

Conclusion

The technical hurdles in migrating legacy data to newer formats and systems are always a challenge. In many cases, it can also be a lack of awareness on the specifics of how to go about such processes. This article has presented “an” approach for getting desktop design calculations from spreadsheets into a structured PLM System through a Model Based Design approach connected to an IoT platform. This can serve as a reference for those who are convinced of moving away from the Document approach, into highly capable PLM Databases, closer to the larger goal of Product validation and acceptance through its lifecycle.