Information 4.0: How HOMAG uses information from the documentation for plant control
New requirements from the development department: Docu data packages for the HOMAG-Service-Cloud
After we had implemented the DITA-based publication solution with SAP integration, HOMAG approached us with a new requirement. HOMAG's development department had approached the technical documentation team and asked how to extract information from the SAP document management system for error descriptions and corresponding solutions to problems. The aim was to load data packages with suitable information into the HOMAG-Cloud and link them to the machines. operators and service-engineers should then be informed of problems on a machine via the HOMAG ServiceAssist app or the HOMAG ServiceRemote and immediately offered the appropriate documents with suggested solutions.
To this end, the developers developers defined in an interface definition which information should be supplied from the technical documentation in order to establish the link between the machine and the documentation.
That's when we at c-rex.net, as a long-standing system integrator of HOMAG, were called upon to implement a solution that was developed according to one of our basic principles, which is: "Use a standard if it exists and adapt it to your needs if necessary!".
Standards, standards, standards! XML, iiRDS, DITA
Since we relied on standards in the previous solution for the creation and automatic publication of technical documentation, namely iiRDS, we wanted to do the same in the development of the new requirement. Therefore, we mapped the list of required metadata against the intelligent information Request and Delivery StandardiiRDS). After all, the request from the development department was about exchanging information between two different systems. And behold! There was almost a 1:1 match.
So it turned out that bundling the information and documents required by the development department in an iiRDS was the appropriate way to go. Only a few adjustments had to be made in iiRDS and in the iiRDS already established at HOMAG.
What is covered by iiRDS? Which extensions were necessary?
There were many requirements for the HOMAG-Cloud that could be covered by iiRDS without any adjustments. A few requirements made it necessary to extend the iiRDS.
In the targeted cloud solution, information should be provided on the percentage of times a solution proposed in the service app has led other users to success. This information was not previously included in the documentation and did not have a suitable equivalent in iiRDS. Therefore, we have added a custom-property for this purpose, extending the iiRDS.
We have realized this via the so-calleddocking points", which are used to store metadata from other standards (e.g. ECLASS) or even custom structures for products and assemblies. And that was a perfect fit for the HOMAG environment. Because HOMAG has been creating assembly-oriented documentation for years.
What does the implementation in DITA look like?
The next step was to see how we could implement this in DITA. Let's take a look at the iiRDS that were already in place at HOMAG.
On the one hand, there are already specialized topics:
HomagFCR (Fault Cause Remedy) derives from the standard "Troubleshooting" topic type.
HomagTask derives from the default topic type "Task".
In addition, there is an MDETask especially for maintenance information, with which the machine establishes a direct connect to the docu. We already reported on this in our first blog post on the HOMAG solution.
We have extended the two specialized topic types, HomagFCR and HomagTask, in such a way that the authors error descriptions can, on the one hand, capture the required metadata and, on the other hand, establish relationships via links in the "Remedy" to the solutions.
What does that mean in concrete terms for editorial work?
The authors create their content as usual and additionally assign metadata in the prolog of the DITA-Topic.
The Remedy in the FCR-Topic are action steps that does not describe directly in the HomagFCR, but inserts as a cross-reference. This cross-reference establishes the relationship to the task in which the solution (workaround) is described.
How does the data get into the HOMAG Service Cloud?
For this purpose, we have extended the publication process integrated in FrameMaker, which already serves different publication channels and provides XLIFF, PDF, control files for the machine and training slides for this purpose. It now generates an iiRDS for the document type "Troubleshooting" and stores it in SAP on a module-specific basis in addition to the other information.
HOMAG ServiceAssist retrieves the information from SAP, where the iiRDS is stored for the respective assembly, and imports it into the cloud application, where the corresponding access and forwarding to the app and the CRM system is then regulated.
What does this look like for users?
users receive suggested solutions on their tablet or smartphone. The basis of the displayed information is in each case an iiRDS, which provides PDF and HTML content that relates precisely to the fault on the machine and provides the possible solutions for it.
You can watch the use of the HOMAG app here on YouTube in the HOMAG channel. Or you can try it out yourself by downloading the HOMAG serviceAssist app from the AppStore.
And with you?
Do you already have an idea of how metadata for iiRDS can be captured in your publication process of technical information and made available to the machine and thus to operators a situational basis with semi- or fully automated solutions? Or have you already implemented a solution? Please do not hesitate to contact us.