💡 Purpose: IEC TR 61666:1997 provides comprehensive software guidelines for CAMAC-based data acquisition and control systems, covering programming models, interrupt handling, real-time data flow, and system configuration management.
1. Scope and Software Architecture
IEC TR 61666:1997 addresses the software layer of CAMAC instrumentation systems, filling the gap between the hardware-level standards (IEC 61662, 61663) and the application requirements of nuclear instrumentation. The technical report defines a hierarchical software architecture with clear separation between the hardware interface layer, the CAMAC system services layer, and the application layer. This layered approach was pioneering for its time and anticipated modern layered software architectures used in LabVIEW, EPICS, and other measurement automation frameworks.
The standard defines three key software components:
- CAMAC System Subroutine Package (CSSP): A standardized set of callable subroutines providing hardware-independent access to CAMAC operations
- Real-Time Executive: Task scheduling, interrupt management, and inter-task communication services for deterministic data acquisition
- Configuration Database: A maintained record of all modules, addresses, calibration factors, and system parameters
⚠ Legacy Software Considerations: Original CAMAC software was typically written in FORTRAN or assembly language. Modern upgrades frequently reimplement the CSSP API using C/C++ or Python while preserving the application-level interfaces to minimize software requalification costs.
2. CAMAC System Subroutine Package (CSSP)
The CSSP defines a standard set of callable routines that encapsulate CAMAC hardware operations, providing hardware independence to application programs. Key subroutines include:
Table 1 — CSSP Standard Subroutines
| Subroutine |
Function |
Parameters |
Return Value |
| CACMD |
Execute single CAMAC command |
N, A, F, data |
Q, X response |
| CACBL |
Execute block transfer |
N, A_start, F, count, buffer |
Words transferred |
| CALAM |
Enable/disable LAM source |
N, A, LAM_mask |
Status |
| CAINI |
Initialize CAMAC system |
Configuration file |
Error code |
| CARDN |
Read module identification |
N |
Module ID, status |
| CATMO |
Set timeout value |
Timeout (ms) |
Previous timeout |
| CAERR |
Retrieve last error details |
— |
Error code, message |
3. Real-Time Data Acquisition and Interrupt Handling
Nuclear instrumentation applications demand deterministic real-time performance for tasks such as neutron flux monitoring, reactor period calculation, and safety parameter display. IEC TR 61666 addresses these requirements through:
- Priority-based task scheduling: Safety-critical acquisition tasks (e.g., reactor protection system scans) are assigned highest priority, while data logging and display tasks run at lower priority levels.
- LAM-driven interrupt service: The CAMAC LAM (Look-at-Me) mechanism is integrated with the host computer’s interrupt system, enabling sub-millisecond response to events such as alarm conditions or data-ready signals.
- Circular buffer management: Continuous data streams (e.g., from pulse-counting scalers) are buffered in circular buffers with automatic overflow protection to prevent data loss during high-rate acquisition.
✅ Software Design Pattern: For high-rate CAMAC data acquisition (above 10,000 events/s), use a double-buffering scheme: one buffer fills via DMA from the CAMAC controller while the other is processed by the application. This technique, recommended in the standard’s annexes, eliminates data loss at the software level.
4. Engineering Design Insights for CAMAC Software
Several practical lessons from IEC TR 61666 remain relevant for modern instrumentation software design:
- Hardware abstraction matters: The CSSP concept proved that a well-designed hardware abstraction layer dramatically reduces software maintenance costs when hardware is upgraded or reconfigured.
- Configuration management is essential: In nuclear facilities, CAMAC configurations change slowly (typically during refueling outages). The configuration database specified by the standard ensures that software always matches the physical hardware configuration.
- Error handling must be comprehensive: The standard emphasizes that all CAMAC operations should check both the Q (module response) and X (data valid) flags, and that timeouts must be implemented for all operations — a lesson still relevant with modern instrumentation buses.
- Qualification traceability: The standard recommends maintaining software qualification records linking each CAMAC function to its verification test — a precursor to modern IEC 60880 software safety standards.
❓ Q1: Can IEC 61666 software be ported to modern operating systems?
A: Yes, the CSSP functional interface is OS-independent. Modern implementations on Linux use kernel-space drivers with userspace libraries, while Windows implementations employ VXD or WDF drivers. The application-level API remains unchanged.
❓ Q2: How is the CAMAC configuration database typically structured?
A: The configuration database typically includes crate maps (module type, station number, serial number), calibration tables (ADC gains, offsets), timing parameters (module-specific settling times), and LAM-to-interrupt vector mappings. Modern implementations use XML or JSON formats.
❓ Q3: What real-time operating systems were commonly used with CAMAC?
A: Historically, CAMAC systems ran under RSX-11, VAX/VMS, or OS-9. Modern CAMAC interfaces often use real-time Linux (with PREEMPT_RT), VxWorks, or QNX for deterministic performance requirements.