The semantics of product data
Pick up your mobile phone or Apple iPad. Look at it. The device contains hundreds of components. Each component has a number. Each number relates to one or more engineering drawings prepared in a complicated system from AutoCAD or another specialist vendor. The component arrived via a delivery service and, in an ideal world, has a sequence of data about the date the order was shipped, when it arrived, and the distributor who put the components in a box and filled the order. Behind the distributor is a manufacturer who either manufactured to an industry-standard specification or to a custom “spec” provided by someone in the component food chain. You get the idea: There are data associated with a single component that, in theory, should be available from a search and retrieval system.
No surprise in this statement: In most manufacturing and production operations, there is no system that aggregates those disparate data and makes those data available to an engineer from a single, easy-to-use interface.
The vendors of enterprise search systems and enterprise resource planning (ERP) systems suggest that “all” product-related data are available. The reality is different. On a visit to a midsize manufacturing firm with Oleg Shilovitsky, the CEO and co-founder of Inforbix, based near Boston, I learned that assembling the specific items of information for a single component is mostly a manual job.
Redundancy and wasted time
Shilovitsky told me, “Most companies waste time redesigning a component. The reason is that the engineer does not have a quick, easy way to see if the company has already created a suitable drawing to a particular specification. So, what happens? Engineers duplicate work already done, which wastes big money and lots of time.”
The walk-around and conversation opened my eyes to a significant gap in the mainstream search and content processing systems. Among the problems I noted was a failure to handle the particular semantic relationship of the particular use of a component within the supply chain, the engineering drawings and associated failure and stress test data, and the particular production process carried out on a machine next to the break room or half a world away in a suburb of Wuhan, China.
“Engineering product data search is not well understood by most people,” Shilovitsky said. “If you are not an engineer and you don’t know how to design and source a component, you have no familiarity with the structured and unstructured data related to a single component, even a common item like a resistor or capacitor.”
A traditional enterprise search system like Microsoft Fast, Autonomy IDOL or IBM OmniFind could in theory be set up to process the information Shilovitsky called to my attention. But the application of those powerful enterprise technologies is most often focused on problems in sales, marketing, litigation and fraud detection.
“The engineer is not the focal point,” Shilovitsky said. “The engineer is important but in a different, specialized world. The company wants product and in many firms, the senior managers are accountants, lawyers and salespeople. The deep knowledge of designing, sourcing and managing at the product design level is not present in a large number of companies. Without that knowledge and without an engineer influencing information policies, existing search systems don’t meet the needs of the engineers.”
Indexing product data
One point that struck me was Shilovitsky’s remark about the semantics of product data. For me, “semantics” means the intended structure and meaning of language. The meaning of an item like a product identification code or a numerical value in an e-mail gains meaning from context. In the product data application for engineering and manufacturing, the meaning depends on a particular context. Indexing a numerical value is meaningless until the row and column header information is included for the specific device, subassembly and component.
Inforbix, a privately held technology company, has developed a system that indexes product data for engineering and manufacturing. The system can intake source data and information from computer-aided design systems such as SolidWorks, Solid Edge from Siemens, and Inventor and AutoCAD from Autodesk, among others. In addition, the system can scour e-mails and technical documentation for data and information about specific engineered components. The system can pull from Oracle and other databases housing product and design engineering data as well as from other systems’ data.
In the Inforbix solution, the user can navigate between connected pieces of data. The system indexes and makes available data from CAD systems and 2-D drawing objects. In addition, the system automatically locates and links to product and engineering information in Excel tables, engineering databases, product data management systems and other enterprise applications.
A system of links
Shilovitsky said, “We deliver cross-silo data access. We also have developed a proprietary and highly precise method for product data semantics support. Efficiency is very important in today’s manufacturing and production settings, so we have focused on a low implementation effort. Unlike a one-size-fits-all search system, we have designed modules and can deliver quite granular applications.”