The Ride Is Running Fine. The Documentation Is Not.

There is a roller coaster at a mid-size amusement park in the Midwest that has been operating safely for eleven years. The ride control system uses a GuardLogix 1756-L73S with a 1756-L7SP safety partner. It manages six block sections, dispatch permissives, brake sequencing, and a distributed E-stop network over CIP Safety. The system works.

The park's ASTM F24 audit is in 90 days. The auditor is going to ask for the ride control system documentation — the safety requirements specification, the logic description, the I/O assignment, the safety integrity analysis, and the test records.

The park has none of this. The ride was installed by a large ride manufacturer who subcontracted the controls to an integration firm. That integration firm was acquired by a larger company two years after installation. The original engineers have scattered. The park has a backup of the GuardLogix program on a laptop in the maintenance office, but nobody on staff programs in Studio 5000.

This is not unusual. According to a 2024 IAAPA survey, 38% of amusement parks reported that they do not have complete documentation for at least one ride control system. For parks that have been operating for more than 15 years, that number climbs to over 60%.

What ASTM F24 Actually Requires

ASTM F24 is the committee that develops safety standards for amusement rides and devices. The primary standard for ride control systems is ASTM F2291 — "Standard Practice for Design of Amusement Rides and Devices." Section 6.4 addresses control systems and requires:

1. Control system documentation including a description of the control logic, I/O assignment, and safety functions
2. Safety analysis identifying safety-critical functions and their implementation
3. Testing records demonstrating that safety functions perform as designed
4. Maintenance procedures for the control system including periodic testing of safety functions
5. Modification documentation for any changes to the ride control system

ASTM F2291 does not prescribe a specific format for this documentation. It does not require a particular programming language or PLC platform. What it requires is that the documentation exists, is complete, and can be produced for inspection.

The standard also references the safety lifecycle concept from IEC 61508 (functional safety) and NFPA 79 (electrical standard for industrial machinery). While amusement rides are not formally required to comply with IEC 61508 in most US jurisdictions, the concepts — safety requirements specification, safety integrity levels, proof testing — are increasingly expected by auditors and insurance carriers.

GuardLogix vs. Standard ControlLogix: Why It Matters

Not all PLC programs are created equal when it comes to safety documentation. A standard ControlLogix 1756-L75 runs a single processor executing one continuous task and optionally several periodic and event tasks. All logic runs at the same integrity level.

A GuardLogix adds a safety layer. The 1756-L73S (or L71S, L72S, L75S, L7SP2) has two processors: the standard controller and the safety partner. The program contains two types of tasks:

Standard tasks: Normal control logic — HMI communication, data logging, non-safety monitoring. These run on the standard controller only.

Safety task: One dedicated periodic task that runs on both the standard controller and the safety partner simultaneously. Both processors execute the same logic independently and cross-check results. If they disagree, the system faults to a safe state.

The safety task has restrictions that standard tasks do not:

• Only safety-rated instructions are allowed (no indirect addressing, no MSG instructions, no custom AOIs)
• Only safety I/O connections are allowed (CIP Safety protocol with built-in diagnostics)
• The safety task period and watchdog are configured separately and have maximum limits
• Safety tags are a separate tag scope — standard tags cannot be written by safety logic

When you upload a GuardLogix L5X file, the safety task and safety tags are clearly identifiable in the XML structure. The safety programs, safety routines, and safety tags all have attributes that distinguish them from standard logic.

This distinction matters for documentation because the ASTM F24 auditor cares primarily about the safety task. The standard task logic — the stuff that updates the HMI display, logs data, and handles operator convenience functions — is operationally important but not safety-critical. The safety task logic — block section permissives, speed checks, brake commands, E-stop response — is what prevents a collision or an uncontrolled dispatch.

Block Section Logic: The Core of Ride Control Safety

Most modern roller coasters (and many flat rides) use a block section control system. The ride track is divided into zones (blocks), and the control system ensures that only one train occupies each block at a time. If a train enters a block that is already occupied, brakes stop it before it reaches the preceding train.

A typical block section controller implements the following logic for each block:

Block occupancy detection: Proximity sensors (inductive or photoelectric) at the entry and exit of each block detect train presence. The safety PLC reads these sensors through safety-rated inputs (1734-IB8S or 1756-IB16S modules) over CIP Safety.

Speed monitoring: Sensors at known spacing measure train passage time to calculate speed. The safety PLC compares measured speed to maximum allowable speed for each block. If speed exceeds the limit, brakes engage.

Brake control: Each block section has a set of brakes (typically pneumatic fin brakes or magnetic brakes). The safety PLC controls brake release: brakes are released (open) only when the downstream block is clear and all permissives are satisfied. Default state is brakes applied — fail-safe.

Dispatch permissive: The station block has additional permissives: restraint verification, operator enable, dispatch button, all blocks ahead clear for the required cascade distance. Dispatch is permitted only when all conditions are simultaneously true.

In ladder logic, a typical block permissive rung looks like this:

RUNG: Block 3 Brake Release Permissive
  XIC  Block_4_Clear           — Downstream block must be clear
  XIC  Block_3_Occupied        — This block must have a train
  XIC  Block_3_Speed_OK        — Train speed must be within limits
  XIC  Safety_Chain_OK         — No E-stops active
  XIC  System_Mode_Run         — System must be in run mode
  XIO  Block_3_Fault           — No faults on this block
  OTE  Block_3_Brake_Release   — Release brakes (allow train to proceed)

Every XIC and XIO condition in that rung is a safety input. Every one needs to be documented: what sensor provides it, what the failure mode is, and what happens when it is false. The output (brake release) is a safety output that must be documented: what actuator it drives, what the response time is, and what the safe state is (brakes applied).

A six-block coaster with dispatch logic, cascade permissives, speed monitoring, E-stop response, and maintenance bypass handling can have 200+ safety rungs. Documenting them manually is a multi-week effort. Parsing the L5X and annotating programmatically takes minutes.

Why Ride Control Documentation Goes Missing

The documentation gap in amusement rides has structural causes:

Manufacturer/integrator separation: The ride manufacturer designs the mechanical system and specifies the control requirements. A controls integrator (often a subcontractor) programs the PLC. The manufacturer delivers a ride package to the park. Documentation responsibility falls through the gap between the manufacturer and the integrator.

One-time commissioning: Ride control systems are programmed once and then run for 20+ years. Unlike a manufacturing process that evolves over time, a roller coaster's control logic rarely changes after commissioning. There is no ongoing engineering relationship that would naturally maintain documentation.

Specialized knowledge: Ride control programming is a niche specialty. The number of integration firms that do this work is small. When one of them changes ownership or loses key engineers, the institutional knowledge for dozens of installed systems disappears.

No regulatory mandate for format: ASTM F24 requires documentation to exist but does not specify a format or a repository. Some parks have binders in the maintenance office. Some have files on an engineer's laptop. Some have nothing.

Cost pressure: Documentation is an engineering deliverable that costs money. When a park is negotiating the price of a new ride, the controls documentation package is one of the first things that gets value-engineered out of the scope.

E-Stop Networks and CIP Safety

Modern ride control systems use distributed safety I/O over CIP Safety (EtherNet/IP with safety extensions). Instead of running hardwired E-stop circuits (the old approach — a series-connected chain of NC contacts), the E-stop buttons connect to local safety I/O modules that communicate with the GuardLogix over the Ethernet network.

The CIP Safety protocol adds a safety layer on top of standard EtherNet/IP:

• Time stamp and time expectation: Each safety packet includes a production timestamp and the consuming device checks that data is fresh
• Unique connection ID: Prevents cross-connection where data from one safety device is misinterpreted as coming from another
• CRC error detection: Dual CRC (one per processor in the GuardLogix) with different polynomials
• Configurable reaction time: The safety system defines a maximum time between valid safety data exchanges — if a packet is not received within this window, the consuming device goes to its safe state

For documentation purposes, the CIP Safety configuration is critical because it defines the system's overall safety response time. If an E-stop is pressed at station 5, the time from button press to brake application at block 3 is:

Button press (0 ms) -> Local safety I/O module scan (typically 4-10 ms) -> CIP Safety packet transmission (1-2 ms) -> GuardLogix safety task execution (safety task period, typically 10-20 ms) -> Safety output packet transmission (1-2 ms) -> Safety output module update (4-10 ms) -> Brake actuator mechanical response (50-200 ms)

Total: roughly 70-250 ms depending on configuration and mechanical response time. The ASTM F24 auditor may ask you to demonstrate this response time calculation — and the numbers come from the GuardLogix safety task configuration and CIP Safety connection parameters, all of which are in the L5X export.

Building the Audit Package

What an ASTM F24 auditor wants to see for a ride control system:

1. System architecture diagram showing the GuardLogix, safety I/O modules, network topology, and field devices
2. Safety I/O assignment mapping every safety input and output to its physical device and CIP Safety connection
3. Safety logic description explaining each safety function in plain English (block section permissives, speed monitoring, E-stop response, dispatch permissives)
4. Safety task configuration including task period, watchdog timeout, and connection reaction times
5. Alarm and fault response documenting what happens for each fault condition
6. Test records demonstrating that safety functions work as designed (E-stop response time, block section interlock verification, speed trip testing)
7. Change log documenting any modifications to the ride control system since installation

Items 2-6 can be generated from the L5X program file. The safety task, safety tags, safety I/O connections, and safety routines are all encoded in the XML and can be extracted, cross-referenced, and presented in a format the auditor can review.

The key is separating safety-critical logic from standard logic. An auditor does not need to review the HMI communication routines or the data logging subroutines. They need to see the safety task — every rung, every condition, every output — with clear documentation of what each element does and why.

Maintenance Bypass and Its Documentation Requirements

Every ride control system has provisions for maintenance — the ability to move trains at reduced speed, bypass certain interlocks for testing, and operate individual actuators for inspection. These maintenance modes are implemented in the PLC and they are among the most safety-sensitive parts of the program.

A typical maintenance bypass implementation:

• A physical keyswitch (safety-rated input) enables maintenance mode
• In maintenance mode, certain non-critical interlocks can be bypassed (e.g., dispatch button held vs. momentary press)
• Critical interlocks (block section occupancy, E-stop) cannot be bypassed under any circumstance
• Speed limits are reduced in maintenance mode (e.g., max 5 ft/s vs. normal max 65 ft/s)
• An audible alarm sounds whenever maintenance mode is active
• All maintenance mode activations are logged with timestamp

The documentation must clearly show which interlocks can be bypassed in maintenance mode and which cannot. This is one of the first things an auditor checks, because an improperly implemented bypass is the most common path to a safety incident during maintenance operations.

In the GuardLogix safety task, maintenance bypass logic typically appears as additional XIC conditions on the non-critical interlock rungs:

RUNG: Dispatch Permissive (Normal Mode)
  XIC  Restraint_Verified
  XIC  Operator_Enable
  XIC  Dispatch_Button
  XIC  Cascade_Clear
  XIC  Safety_Chain_OK
  OTE  Dispatch_Permitted

RUNG: Dispatch Permissive (Maintenance Bypass)
  XIC  Maintenance_Key_Active
  XIC  Restraint_Verified     — Still required in maintenance
  XIC  Operator_Enable        — Still required in maintenance
  XIC  Safety_Chain_OK        — Still required in maintenance
  XIO  Cascade_Clear          — Cascade check bypassed
  OTE  Dispatch_Maint_Permitted

If you cannot produce this documentation showing exactly which conditions are and are not bypassed, you have an audit finding.

The Insurance Dimension

Beyond regulatory compliance, ride control documentation has an insurance dimension that is becoming increasingly important.

Amusement ride insurance carriers (the specialized underwriters who cover ride liability) are raising premiums and adding requirements for facilities that cannot demonstrate adequate controls documentation. Some carriers now require:

• Annual safety PLC program review by a qualified third party
• Documented proof testing of safety functions at specified intervals
• Configuration management (program backups with change tracking)
• Response time documentation for safety-critical functions

A facility that cannot produce its ride control documentation may face premium increases of 15-30%, additional exclusions, or in extreme cases, inability to obtain coverage at all. This is the financial pressure that is driving parks to address the documentation gap even when regulatory enforcement has been historically light.

Getting Started: The 90-Day Audit Prep Plan

If your ASTM F24 audit is approaching and you do not have complete ride control documentation, here is the practical path:

Week 1-2: Inventory and backup. Identify every PLC in every ride control system. Connect to each one and save a current backup. For GuardLogix, export the .ACD as .L5X. Label each file with the ride name, PLC location, and backup date.

Week 3-4: Automated documentation. Upload each L5X file to a PLC analysis tool. Generate the safety I/O map, the safety logic description, and the alarm/fault response documentation. Review the output for accuracy — the automated analysis gets you 90% of the way, but ride-specific context (why a particular timer is set to 800 ms, what a specific proximity sensor detects) requires human review.

Week 5-6: Gap analysis. Compare the generated documentation against ASTM F2291 requirements. Identify gaps — typically missing response time calculations, incomplete fault analysis, and undocumented maintenance bypass logic.

Week 7-8: Fill the gaps. Complete the response time calculations from the safety task configuration. Document fault conditions and responses. Describe the maintenance bypass logic in detail.

Week 9-10: Testing. Perform proof testing of safety functions and document the results. Test E-stop response, block section interlocks, speed trip functions, and dispatch permissives.

Week 11-12: Review and package. Compile the complete documentation package, review for consistency, and organize for presentation to the auditor.

Twelve weeks is tight but achievable. Without automated PLC analysis tools, the same process takes 6-12 months of engineering time.

Get Started

Upload your ride control GuardLogix program to Controls Foundry for free instant analysis. We will parse the safety task, map the safety I/O, document the block section logic, and give you the foundation for your ASTM F24 audit package.

No Studio 5000 license required. No controls integrator visit. Just upload the L5X file and get answers.

Upload your PLC program to Controls Foundry