Generating AASX Files

Generating AASX Files

When your product data is ready, you turn it into an AAS file. This is the payoff: a standard file you can hand to a customer or push into a repository.

---

The three formats

You can export in three formats. They hold the same data but differ in what travels with them.

Format	What it is	Includes documents and images?	Use it for
AASX package	A single self-contained file (a zip) holding the AAS plus every referenced document and image.	Yes	Sending to a customer, or opening in AASX Package Explorer.
JSON	The AAS data on its own. Readable and easy to diff.	No	Feeding an AAS REST API or another system, or checking the content.
XML	The same data on its own, in XML.	No	Systems that expect XML.

The key difference: only the AASX carries the actual files. In JSON and XML the document and image references are still there, but the bytes are not, so a customer receiving a JSON export would not get your PDFs. When in doubt, send the AASX.

---

Type versus instance

You can export at two levels, and they are different assets.

• A type export describes the product model. It carries everything shared by every unit: nameplate, technical data, documents, markings. It has no serial number.
• An instance export describes one physical unit. It carries the serial number, build date and version overrides on top of everything inherited from the type.

See Key Concepts for the type-versus-instance idea, and Product Instances for units.

---

Where to export from

From	What you get
A product's page (top right Download menu)	The type-level file, in AASX, JSON or XML.
An instance row (its Export or publish menu)	That one unit's file, including its serial number.
The parse page (Download AAS after a parse)	A decoded type code as a file, without creating a product. See Parse a Type Code.

The file downloads to your browser, named after the product or code.

---

Publishing to BaSyx

Instead of downloading a file, you can push a product straight into a running BaSyx AAS repository with Publish to BaSyx. It sends the shell, submodels, concept descriptions and files in one step.

This button only appears when a BaSyx server has been configured for your installation. If you do not see it, BaSyx is not set up, and downloading a file is your route.

After publishing, the product's badge in the Product Catalog shows Published, and if you edit the product afterwards it turns to Out of sync until you publish again.

---

Which format should I pick?

• Sending it to someone, or archiving it? AASX. It is complete on its own.
• Loading it into another system or an API? JSON, unless that system specifically wants XML.
• Just checking what the file contains? JSON is the easiest to read.

---

Hints

• Use AASX when documents matter. A JSON or XML export looks complete but leaves the PDFs behind.
• Check the product is ready first. In the catalog, a product marked Not ready is missing a mandatory field and will not produce a valid file. Fix that before exporting.
• Keep exported files under version control or backed up. The app does not keep a copy of what you exported.

For technical users

Exports are built on demand by the AAS environment builder over AasCore.Aas3_0 (metamodel 3.0). AASX is an OPC package embedding the digital files; JSON and XML serialise the Environment alone via the AAS JSON and XML serializers, so File elements keep their paths but carry no bytes. Type exports use AssetKind = Type; instance exports use AssetKind = Instance. Publish to BaSyx pushes shells, submodels, concept descriptions and files to the configured repository and records a fingerprint used for the catalog's sync status.