I really like how VC is structured and I think it’s does quite a lot right to implement Industry 4.0 concepts such as asset description, interfaces etc. Some of the most important aspects in this regard are standardization, open access and protocols (for example OPC UA, formalised process descriptions etc.)
One designated standard for asset description and data exchange is AutomationML and I noticed Visual Components is a member of the AutomationML association: https://www.automationml.org/o.red.c/mitglieder.html
AutomationML describes topology (CAEX), geometry and kinematics (COLLADA) as well as logic (PLCopen XML). VC basically uses all these concepts, however I have not seen official support for AutomationML yet.
Is there any plan to adapt AML or parts of it in the future?
What do you want to do with AML in Visual Components? For example, do need it as a way to easily share data with other teams? Is the emphasis on importing and exporting the kinematics, topology and configuration of devices, or PLC related side of AML? Note I am aware TwinCAT already supports import/export of AML and other software as well.
it would also help to know the software used in other teams, e…g use case of Solidworks <> Visual Components <> other, but you can DM me that info or I can contact you directly if you do want to share here.
We are testing Visual Components as a virtual commisioning tool and AutomationML support would be really interesting for us.
We are trying to develop our suppliers and they work with different CAD software and PLC / robot brands, this kind of standardization seems to be the future of this technology.
Yes, in cases where different teams need to work with the data. Depends on the need. One need might be for quick sharing of geometry and kinematics. Another need might be concerned with EPLAN data. And so on.
Yes, I would like to know more about the use cases about the quick sharing of geometry and kinematics. Is it possible to give me more in detail about it?
If we are not talking about the technical details rather the use cases themselves, the following is public information that you can use as a reference.
Here, one thing to highlight are pages 26 and 27.
So if teams, supplier, etc. are using different CAD systems or some other team is just focused on OLP or IO, etc. then it can help to have a common format that eliminates the need to model things again and again, especially in cases where a behavior emulator mentioned in page 27 is used to drive the kinematics of the model.
Thank you for offering me the documents. I have a question based on the ppt from Siemens. I see on Page 7, the kinematics information is described in STEP format, but in my opinion, if we export a STEP format model from NX MCD, some kinematics information will be lost, such as the predefined rigid bodies, collision bodies, joints, sensors, actuators, etc. And these kinds of information are sometimes relevant to the specific features (such as faces, points) of the geometry models of components. How to build the relationship between the kinematics information above and the relevant STEP geometry files in AutomationML?
Good question. That page and its subsequent page indicate the goal of supporting the use of AutomationML, which uses Collada file format for geometry and kinematics. So the JT and STEP files are examples of current situation and the need to convert them to AML data (neutral format) that can be used by other tools without requiring additional modeling. For example, you import a JT or STEP file, model it, and then need to share the geometry and kinematics of your model. Do you export to STEP? No, the system you did all the work in could export your work to AML, and then the AML data can be used in other software without the need to remodel everything or lose data.
It is not about converting STEP or JT to DAE file format.
Some software focuses on a particular aspect of AML, for example TIA Portal and WinMod in regards to EPLAN data and IO configuration. And the companion specification for OPC UA and AML has been around for a few years, but I’ve never used that spec and I don’t remember if it mostly focused on PLCopen part of AML.
How the kinematics and geometry are built in AML is too much to go into here, but how it is done is documented in the specification/AML website.
One thing to point out is to be careful with the abbreviation of AML since it might mean something different in other software. That is one reason to more commonly use AutomationML when discussing the topic unless it is clear what AML means in the context of that situation.
Thank you for your comment. Yes, as the AutomationML whitepaper says, the geometry and kinematics information should be contained in Collada file, which is integrated into the AutomationML architecture. I would like to see how to generate an AutomationML “package” (.aml file with collada files) from virtual commissioning software (such as Siemens NX MCD and Visual Components), as I know the software do not support to import or export AutomationML file by itself, we have to develop plug-ins. Are there already plugins for this? I would like to see use cases of this if possible.