Industrie 4.0 Data: What German Buyers Expect Before a Demo
A polished demo does not answer the difficult industrial questions. German buyers will want to know what the data means, where it comes from, how it moves, who can use it and what happens when the connection fails.
Prepare that evidence before the first demonstration. Otherwise the team spends the meeting translating labels, defending a custom interface and promising documents that do not yet exist.
What data should be ready before an Industrie 4.0 demo?
Prepare a machine and asset identifier, defined data fields with units, update frequency, interface method, access roles, error states, retention rules and a sample export. If the product supports the Asset Administration Shell, state which submodels and identifiers are implemented rather than using the term as a general claim.
Germany's Federal Ministry for Economic Affairs and Energy describes the Asset Administration Shell as a uniform virtual representation and communication interface. Its Manufacturing-X overview puts interoperability and data sovereignty at the centre of cross-company data spaces.
Those are useful directions. A buyer still needs product-specific proof.
Industrial demo readiness map covering data model, Asset Administration Shell, interfaces and access controls.
Build a demo data sheet
| Field | What to state | Common failure |
|---|---|---|
| Asset identity | Identifier, namespace and lifecycle rule | Name changes between systems |
| Data point | Meaning, unit, type and valid range | Label is visible but undefined |
| Source | Sensor, controller, calculation or manual input | Calculated value appears measured |
| Frequency | Sampling and transmission interval | “Real time” has no number |
| Quality | Missing, stale and invalid flags | Bad values look valid |
| Interface | Protocol, format and version | Custom connector is described as standard |
| Access | Role, authentication and audit record | Demo account has unrestricted rights |
| Export | Format, time zone and identifier | CSV cannot be reconciled later |
Give the buyer this sheet before the demo. It lets the technical team prepare relevant questions and reduces time spent on cosmetic screens.
Separate the machine model from the dashboard
A dashboard is one view of the data. It is not the data model. Show the hierarchy from company or site to line, machine, component and signal. Explain how identifiers persist when equipment is replaced or moved.
If the system uses an Asset Administration Shell, name the supported shell version, relevant submodels and exchange route. If it only exports a proprietary JSON structure, state that clearly. Compatibility can still be useful without being called interoperability.
Demonstrate failure, not only normal operation
Industrial systems fail in ordinary ways: a sensor becomes stale, a gateway loses connection, a time stamp arrives out of order or an operator enters an invalid value. Include one planned failure in the demo.
Show:
- how the fault is detected;
- how the value is labelled;
- whether an alert is generated;
- what is buffered locally;
- what happens after reconnection; and
- how the event appears in an audit record.
This reveals more about operational readiness than another animation of a healthy machine.
Define the data-use boundary
The buyer should know whether data is used for monitoring, optimisation, maintenance, model training or benchmarking. State where processing occurs and whether the supplier can use customer data for another purpose.
Prepare a simple responsibility table:
| Decision | Supplier | Customer | Joint |
|---|---|---|---|
| Data-field definition | ✓ | ✓ | |
| Source-system access | ✓ | ||
| Connector configuration | ✓ | ✓ | |
| User access approval | ✓ | ||
| Algorithm change | ✓ | ✓ | |
| Operational response | ✓ | ✓ |
Adjust it to the actual contract. The value is in making ownership discussable before purchase.
Give security reviewers something concrete
Do not claim the platform is secure because it uses encryption. Provide an architecture at the right disclosure level, supported authentication methods, role model, logging, update process, vulnerability contact and data-flow boundary. Keep credentials and sensitive network details controlled.
For a remote demo, use synthetic or approved data. Mark it visibly. Do not present a simulated result as a live production example.
Turn the demo into a case record
After a pilot, record the baseline condition, data connected, intervention, observation period, exceptions and outcome. Our article on Industrie 4.0 case studies explains why the process matters more than a technology label.
The engineering sector page shows how technical buyers move from capability to evidence. Our custom software work starts by mapping the data and operational decision, then decides what interface is needed. If the dashboard is ready but the data definitions are not, start with the problem.
Run a buyer rehearsal
Ask an engineer who did not build the demo to trace one value from sensor or source record to screen and export. They should identify its unit, update interval, transformation and quality state. Repeat the exercise for a missing or corrected value.
Then give the integration sheet to an IT or OT reviewer. Ask which authentication, certificate, network and support questions remain unanswered. Resolve the definitions before polishing sample charts.
Keep a demo configuration record containing software version, data set, enabled interfaces, synthetic-data status and known limitations. This stops sales teams from presenting an old demonstration as current capability. If a feature is a prototype, label it. If an integration was built for one customer, state whether it is a supported product feature or project work.
After the meeting, record the buyer's questions by category. Repeated questions belong in the data sheet, architecture note or website. One-off security and project details should remain in the controlled response.