Product Type

Product Type

A Product Type is one of your products described once, for example "Centrifugal Pump PUMP3000". Every physical unit you build reuses this description, so you enter the shared details a single time.

The app calls it a Product model on screen. It is the same thing.

---

Product model or single unit?

	Product model	Instance
What it is	The product as a design	One physical unit you made
Example	PUMP3000	PUMP3000, serial SN-2025-001234
Holds	Name, specs, documents, certificates	Serial number, build date, HW/FW/SW versions
How many	One per product	As many as you produce

An instance inherits everything from its product model. You only enter what is unique to that unit.

➡️ Product Instances

---

Creating one

From the Product Catalog, click Add product. There are two ways to do it.

1. By hand. Fill in the form described below.
2. From a type code. If your products use a structured code such as PUMP-3000-AB, the app can split that code into these fields for you. See Type Code Overview.

Products created the second way carry a "From type code" chip on their page.

---

The form

Manufacturer

Field		What to enter
Select Manufacturer	*	Which of your companies makes this product. Set them up first on Manufacturer Details.

Product hierarchy

Three levels, from general to specific. Root and Family are both required, so every product lands somewhere in the catalog.

Field		What to enter
Product Root	*	The broad category, for example Pumps. Type the English name and the app searches your existing roots. Pick one and the German name, plus any other languages, fill in automatically. This keeps your catalog consistent.
Product Family	*	The sub group, for example Centrifugal Pumps. Suggestions are filtered by the root you picked.
Product Designation	*	The product's short name, for example PUMP3000. This is the name shown everywhere in the app.

Root and Family are multilingual. You get an English and a Deutsch box, plus Add language for more. One language is enough to start with.

Variant identifier

Field		What to enter
Product Type	*	A code that tells buildable variants of the same product apart, such as frame sizes or build options. For example MR 7436.

This one is confusing, but it is deliberate. The field is called "Product Type" while the whole record is also called a Product Type. The field is only the variant code. It is separate from the three level hierarchy above.

Ordering information

Field		What to enter
Order Code	*	The code a customer uses to order it, for example FMABC1234.
Article Number		Your internal product number, for example FM11-ABC22-123456.

Default version info

These are the defaults that every instance inherits. Any instance can override one of them on its own. That is useful when you ship a firmware update partway through a series.

Field	What to enter
Hardware Version	For example 4358.
Firmware Version	For example 3.0.1.
Software Version	For example 2.1.0.

Origin and image

Field	What to enter
Country of Origin	Where this product is normally made. An instance can override it if a batch was built somewhere else.
Product Image	A photo of the product. Use Add Image.

Finish with Save Product, or leave with Cancel.

---

The product page

Once saved, the product's own page is the home base for everything else.

The identity card

Across the top you see the product image, or its first letter if there is no image, then the designation and a Product model badge. If the product came from a type code there is also a From type code chip.

Below that, at a glance: Product Root, Product Family, Order Code, Variant Identifier and Article No. A dash means the field is empty.

On the right there is a counter showing how many instances exist. Click it to jump straight to them. Next to it sit Download, Publish to BaSyx and Edit.

Edit changes only these identity fields. Everything else is edited in its own section.

The section tiles

The overview is a grid of tiles, one for each kind of product data. Click a tile to open that section, then use Back to overview to come back. Each tile shows either a grey Empty chip or a green tick with a count, for example 2 files.

Always shown:

Tile	What goes here	Guide
Technical data	Specifications a buyer compares before purchase	Technical Data
Handover documentation	Manuals, datasheets and certificates	Documents
Markings	Proof of compliance such as CE	Markings

Shown only once you use them. Add them with the Add information tile:

Tile	What goes here	Guide
3D models	CAD files and 3D previews	3D Models
Carbon footprint	CO2 figures per life cycle phase	Carbon Footprint
Component characteristics	Reliability and safety figures such as MTBF, SIL and PL	Component Characteristics
Asset properties	Extra nameplate facts unique to this product	Asset Properties

This keeps the page short. A workshop that never publishes CO2 figures simply never sees that tile.

The × on an optional tile removes it. If the tile is empty it just disappears. If it holds data, the app asks you to confirm and then deletes that data. It does not only hide the tile.

There is no progress bar and no percentage. A product is finished when the tiles you care about are filled in. The rest are meant to stay empty.

---

Instances

The Instances section lists every serial numbered unit you have registered. The table shows the number, Serial Number, Manufacture Date, Hardware / Firmware / Software, Country, and buttons for Edit, Documents, Download and Delete.

Instances inherit all product level data and carry only what is unique to the unit.

➡️ Product Instances

---

Publishing the product

Download at the top right offers two formats.

Choice	What you get	Use it for
AASX package	Everything in one file, including documents and images	Sending to a customer, or opening in AASX Package Explorer
JSON	The AAS data only, with no attachments	Feeding another system, or checking the content

Publish to BaSyx pushes the product straight into a connected AAS repository. The button only appears when a BaSyx server has been configured. If you cannot see it, that is why.

Publishing also sets the product's badge in the Product Catalog to Published. If you edit the product afterwards, the badge turns red and reads Out of sync until you publish it again.

Both buttons send the product model. To publish one specific unit, use the download menu on its row in Instances. That file carries the serial number.

➡️ Generating AASX Files

---

Tips

• Get the hierarchy right first. It drives how the catalog groups everything, and changing it later means editing each product.
• Fill in Technical data, Handover documentation and Markings. Those three cover what most customers ask for.
• Ignore the tiles you do not need. An empty optional section is not a gap.

For technical users

A Product Type is exported as an asset with AssetKind = Type. Each instance is AssetKind = Instance. The identity fields populate the Nameplate submodel (IDTA 02006-3-0), and the variant identifier field is ManufacturerProductType.

Section tiles map to submodels as follows. Technical data → 02003-2-0. Handover documentation → 02004-2-0. Markings → Nameplate Markings. Asset properties → Nameplate AssetSpecificProperties. Carbon footprint → 02023. Component characteristics → Reliability (02013) and Functional Safety (02014). 3D models → 02026.

The AASX embeds document and image binaries. The JSON export is the AAS environment on its own, so file references resolve to nothing outside a package.