The Car Stacker Safety Requirements Most Projects Miss

What the standards, the verification process, and the wider fire-safety framework actually require — and where many projects are left exposed.

A car stacker can look finished long before it is truly safe.

That is one of the quietest and most expensive truths in this industry.

On paper, the project may appear complete. The equipment has been installed. The platforms move. The controls respond. The builder is pushing for handover. The developer wants practical completion. The supplier has a package of documents ready. And to anyone standing there on the day, it can feel as though the hard part is over.

But that moment — the moment everyone relaxes — is often where the real exposure begins.

Because in automated parking systems, there is a difference between a machine that has been delivered and a system that has been properly verified.

Most people do not see that difference until something goes wrong.

Sometimes it begins with a damaged vehicle. Sometimes with a repeated fault nobody can explain properly. Sometimes with a user incident. Sometimes with a defect dispute that grows teeth the moment an insurer, expert, or lawyer starts asking for evidence. And when that happens, the conversation changes very quickly.

Nobody cares any longer that the machine moved on the day of handover.

The question becomes much more serious:

What, exactly, was checked before this system was accepted?

That is the question too many projects leave unanswered.

The false comfort of “it was commissioned”

Over the years, I have seen the same pattern repeat across stackers, transfer systems, and more complex automated vehicle parking installations.

A project team uses the word commissioned as if it settles the matter. It sounds complete. Professional. Reassuring. It gives everyone a convenient sense that the system has crossed some invisible line into safety and compliance.

But in practice, that word often hides a wide range of realities.

At one end, it can mean a disciplined verification process backed by proper testing, recorded results, and traceable evidence.

At the other end, it can mean the machine cycled, the installer demonstrated basic movement, a few faults were cleared, and the project moved on because the programme had no room left for deeper scrutiny.

Those are not the same thing.

And the standards do not treat them as the same thing either.

What AS 5124 and EN 14010 are really asking for

AS 5124:2017 and EN 14010 are not loose reference documents built around general intentions. They are structured safety standards dealing with the design, manufacture, erection, and commissioning stages of power-driven parking equipment, and they require the relevant safety measures and information for use to be verified.

That matters because many projects still behave as though compliance lives primarily in the design package, the product brochure, the supplier declaration, or the handover certificate.

It does not.

The standards place real weight on verification.

Under Clause 6, the safety requirements and protective measures in Clauses 5 and 7 are to be verified through a defined framework. That framework is not built around guesswork or generic sign-off language. It uses specific methods such as design checks, visual checks, measurements, functional tests, loaded tests, and specific verification. Where part of the machine cannot be verified before despatch because of its size, assembly, or installation condition, that verification is required at the place of use. The results and tests are to be recorded in a signed report.

That is a far more serious requirement than most handover conversations acknowledge.

It means a machine is not proven safe simply because it was installed without obvious drama.

It means a project is not protected simply because a supplier says the system complies.

It means the real standard is not confidence.

It is evidence.

Where projects start to drift away from the standard

This is where the industry gets itself into trouble — not always through blatant negligence, but through pressure, assumption, and habit.

A project team is tired. The programme is compressed. The parking package is only one part of a much bigger construction closeout. Everyone is dealing with multiple trades, multiple defects, commercial deadlines, and the constant pressure to move from “almost finished” to “done”.

So the threshold quietly shifts.

Instead of asking whether the installed system has been verified properly, people start asking whether it is working enough to hand over.

That is the wrong threshold.

Because a stacker can appear operational while still carrying unresolved risk in the very places the standards are trying to force people to examine: safety logic, sensing, interlocking, fault behaviour, control response, load-related functions, and the completeness of the documentation trail.

That is why so many of the worst problems do not show themselves at the beginning. They stay hidden until the building is live, the system is under pressure, and the people originally involved in the handover have already moved on.

Verification Is Not Optional

This is where many people misunderstand what proper commissioning actually means.

Clause 6 of AS 5124 and EN 14010 does not treat verification as a vague sign-off exercise. It sets out a structured verification regime for the safety requirements and protective measures in Clauses 5 and 7, covering both type verification and individual verification. And where part of the machine cannot be verified before despatch because it is assembled on site, that verification must be carried out at the place of use.

The standards identify a number of verification methods, including:

• Design check (D) — confirming the design of the machine, system, or component is adequate to meet the standard

• Visual check (V) — confirming required physical elements, warnings, markings, documents, or guarding are actually present

• Measurement (M) — confirming measurable parameters such as safety distances, dimensions, or electrical values have been achieved

• Functional test (FT) — confirming that, in an unloaded working operation or normal cycle, the machine and all safety devices work as intended

• Loaded test (LT) — confirming the performance of relevant safety devices and their adjustments under actual test conditions beyond a basic functional cycle

• Specific verification (SV) — confirming specialist matters such as electrical and EMC compliance where stated parameters must be demonstrated

That matters because this is not the language of paperwork.

It is the language of evidence.

It means commissioning is not supposed to be a paper ritual completed from an office desk. It is not meant to be reduced to a general statement that the system was tested. It is not satisfied by a supplier demonstration, a handover pack, or the fact that the platforms moved during a site visit.

A proper verification process requires people to be physically present, to inspect what is actually installed, to test what needs to be tested, to measure what needs to be measured, and to record the outcome in a signed report. Clause 6.1 is explicit on that structure, and the verification table itself runs across multiple pages because the standard is forcing the project team to deal with the installed machine in detail — not in theory.

This is exactly why I keep saying that commissioning is not just a paper.

Because if the process has not dealt with the real machine, on the real site, against the relevant verification methods, what you have is not a defensible commissioning record.

You have an assumption.

And assumptions become very expensive the moment somebody asks for proof.

Why this distinction matters in practice

When commissioning is treated properly, it should be capable of showing:

• what was checked

• how it was checked

• whether it was verified before despatch or on site

• which items required functional or loaded testing

• what evidence exists for the result

• who signed off on that result

That is the difference between a system that was merely handed over and a system that was genuinely verified.

In my experience, a large number of installed systems do not have a complete and traceable documented record of that process. And that is where the real problem begins — because the gap usually stays hidden until there is a fault, a vehicle damage event, a repeated defect, a safety incident, or a dispute serious enough that somebody finally asks to see the verification trail.

That is when a thin commissioning file stops looking administrative and starts looking dangerous.

The part most people underestimate: safety functions must be proven, not assumed

One of the clearest examples sits in the automatic parking provisions.

EN 14010 requires automatic parking equipment, depending on the design, to include one or more automatic fault-detection devices addressing safety gear or safety nut switches, slack lifting-element switches, ultimate-position switches, trip devices, load-carrier safety switches, door safety switches, height and width sensors, and heat or movement sensors. If a fault or hazardous condition is detected, the user or attendant must receive a clear warning. Where appropriate, linked equipment must be slowed or stopped in a controlled way, and where there is risk of injury, an automatic stop is required, with restart remaining under safety-device control.

That is not just technical decoration.

That is the actual safety behaviour of the installed system.

And this is where experience matters. Because on paper, everyone agrees those protections are important. In a brochure, they sound impressive. In a specification, they are easy to list. But on site, the real question is much harder:

Were those functions actually checked on the installed machine in a way that would still stand up months or years later if someone asked for proof?

That is a very different question from “was the machine demonstrated?”

And it is usually the more important one.

Why documentation is never “just paperwork”

Another mistake the market makes is treating documentation as an administrative afterthought.

It is not.

Clause 7 requires the instruction handbook and information for use to include the duties and conditions under which the equipment is intended to be used, including the vehicles to be handled and their limiting characteristics, the operating conditions, environmental conditions, public or non-public use, and the details of safety functions together with the list and location of safety devices. It also points to installation-related information and emphasises the need for re-commissioning after modification in accordance with the manufacturer’s instructions.

That matters enormously in the real world.

Because when there is a dispute, weak documentation is never neutral. It does not sit quietly in the background. It becomes part of the problem.

If the system’s operating limits are not clear, if the safety logic is not properly described, if the relevant devices are not identified, if the conditions of use are vague, or if post-modification re-commissioning is treated casually, then the project has not merely produced bad paperwork.

It has weakened the safety case itself.

And once you understand that, you start looking at handover packs very differently.

The Australian issue most teams still do not take seriously enough

In Australia, there is another layer that too many people underestimate.

AS 5124 itself already flags that fire risk is not something to ignore. Its Australian appendix draws attention to sprinkler protection, smoke control, firefighting considerations, structural integrity in fire, and the need to think carefully about shutdown and restart behaviour in the context of fire alarm events.

But the more important practical point is this:

For Victorian projects involving automated vehicle parking systems, that conversation does not stop at the machine standard.

FRV Guideline 32 makes clear that compliance with AS 5124 is a prerequisite for its approach to firefighter safety, and it says Appendix ZX5 should be given equal regard to the body of the standard. It then goes further, dealing with issues such as sprinkler protection across the storage area, additional sprinklers within storage bays and pits, controlled automatic shutdown, power isolation and status identification, ventilation, hydrants, signage, and access and egress requirements for firefighters.

That is a major point.

Because it means a stacker or automated parking system cannot be treated purely as a mechanical package. In Australia — and particularly in serious design and approval environments — it sits inside a wider fire, access, intervention, and building-risk framework.

So a project may feel comfortable because the machinery package has been supplied and the platforms move, while still carrying unresolved exposure at the building and emergency-response level.

That is not a small gap.

That is exactly the kind of gap that turns “we thought it was fine” into a very expensive sentence later.

Why this matters commercially

It is easy to talk about all of this as an engineering issue.

That would be a mistake.

Because by the time most people start paying attention, it is no longer just technical.

It is commercial. Contractual. Legal. Insurance-driven.

Once the system is accepted, the risk starts moving through the project chain.

If the verification trail is weak, the developer’s acceptance position weakens.

The builder’s handover defensibility weakens.

The owner’s leverage under warranty weakens.

The insurer’s comfort weakens.

And the legal position of everyone who relied on those assumptions can weaken with it.

That is why these safety requirements matter so much.

Not because the standards are academically interesting.

Because they sit right at the point where technical reality and commercial exposure collide.

And when that collision happens, the machine is no longer the whole story.

The evidence is.

What proper verification should feel like

A serious process should feel heavier than a demonstration.

It should leave a trail.

It should be capable of showing that the relevant design assumptions were checked, the physical protections were reviewed, the necessary measurements were taken, the required functional and loaded tests were completed where applicable, on-site verification was undertaken for matters that could not be checked before despatch, and the results were recorded properly in a signed report.

It should also leave behind a proper information package for the people who will actually live with the system: owners, operators, maintainers, and anyone later asked to review what was delivered. That means the conditions of use, prohibited uses, safety-device information, and post-modification requirements are not vague or buried. They are clear.

That is what genuine discipline looks like.

Not a quick run-through.

Not a vague statement that the machine was tested.

Not optimism dressed up as compliance.

A trail of proof.

The question worth asking before you accept any system

If you are a developer, builder, building owner, strata representative, insurer, certifier, or legal team dealing with a car stacker or automated parking system, the most important question is not whether the machine looks complete.

It is this:

Can you show me the verification record for the installed system — including what was checked, how it was checked, and the evidence that the relevant safety requirements were actually verified?

If the answer is thin, generic, or built mostly around supplier assurance, then the project may be relying on confidence where it should be relying on proof.

And in this sector, that is a dangerous trade.

Because problems in automated parking systems are rarely defined by the day everything looked fine.

They are defined by the day someone finally asks for evidence.