The label does not assess the installation
A robot may be designed for collaborative applications, but that description is not enough to determine whether a person can work safely alongside it. Safety depends on the complete application: the task, movements, load, tool, where people are located, and the measures used to prevent or limit hazardous interactions. EU-OSHA describes a collaborative application as the broader system in which people and robots interact; the robot’s characteristics are therefore only one part of the assessment of the whole system.
The documentation available for this review does not allow us to confirm the scope or current status of specific technical standards, or that a particular standard or specification certifies an installation. It is therefore best to treat “collaborative” as a description of intended use or certain capabilities, not as automatic approval of every integration.
Nor should “without a fence” be taken to mean “without protective measures.” An application may require physical separation, presence detection, movement limits, or other measures determined by the risk assessment. The decision depends on foreseeable hazards and on how the complete system is used. The object being handled, the edges of a tool, or a person’s access to the robot’s path can change the risk.
What to consult in standards and documentation
Start by identifying the jurisdiction, type of machine, and planned commissioning date. In the European Union, consult the applicable legislation in force and official sources: an explanatory page or technical standard does not replace that check. EUR-Lex provides a summary of the European machinery-safety framework, but the summary alone does not determine which specific obligations apply to a particular installation.
The source package for this review does not allow us to verify current editions of specific ISO standards or their national adoption. Before citing or applying a standard, confirm its edition and current status with the relevant official source, and check how it relates to the regulations applicable to the project. A public information sheet may describe its general scope, but it does not replace the complete text of the standard.
Ask the manufacturer for documentation relevant to the model and configuration offered: manuals, operating limits and conditions, safety instructions, information on safety functions, and known restrictions. Check that it applies to the planned software, accessories, and load; do not extrapolate data from similar equipment. Ask the integrator for documentation on the finished cell and an explanation of how protective devices relate to the robot’s control system. A sales sheet can help guide the conversation, but it does not prove that the measures work in the specific application.
Assess the complete system and task
The assessment should describe the actual work, not a simplified representation of the machine. Include the robot, its base and stability, the tool, the workpiece, cables, and other elements that could strike, snag, cut, or crush. Consider intended and foreseeable movements during loading, unloading, cleaning, adjustment, fault recovery, and maintenance. Who may enter the area, from where, and with what training also matters. If the task changes, the assessment may no longer represent current use.
Map the spaces occupied by the robot and people during the cycle, including the load’s path and areas accessible from outside. Examine obstacles, trapping points, and entry routes that may be outside the detection field. Consider response times and the distance needed to stop before reaching a hazardous area, but do not treat an isolated calculation as sufficient proof: it must correspond to the system’s actual components, configuration, and operating conditions.
Operation also includes non-routine situations. Removing a jammed part, restarting after an alarm, or carrying out maintenance can expose someone to unexpected movement. Document who may perform those tasks, which operating modes are available, and what conditions must be met before the cycle can resume. When the tool, workpiece, program, speed, layout, or protective measures change, review whether the previous assessment and validation remain relevant. An installation does not remain safe merely because it passed an initial review.
Check the protective measures, not just their names
Measures must address the hazard they are intended to control and work in the actual layout. If speed-and-separation monitoring is proposed, ask how presence is detected, which area the sensor covers, what happens if detection is lost, and how a stop is ensured. FANUC publishes manufacturer information about collaborative robot systems and safety aspects. That material can help frame questions about the application, but it is not an independent validation of a specific installation.
If the strategy allows physical contact, the analysis must consider how contact could occur and what object or tool would be involved. The workpiece may have sharp edges, the tool may concentrate force, and contact may affect different parts of the body. The available documentation does not support numerical thresholds that can be applied to a specific case; do not reuse commercial figures as if they were general authorization.
Ask for evidence that the integrated system has been checked: which functions were reviewed, in what configuration, under what conditions, and with what documented results. Check what happens in foreseeable failures, loss of power or signal, opening of a guard, and a person entering the area. Checks must reflect the load, tools, program, and design that will actually be used. Do not accept a general claim that a product is collaborative, a label, or a certificate whose scope is unclear as proof.
Questions for the manufacturer and integrator
Before accepting a proposal, ask the supplier to identify the task’s hazards, the planned measures, and the assumptions on which they depend. Ask which safety functions are used and which components are involved; how people are detected; which areas are not covered; which limits are configured; and what behavior is expected in the event of failures or changes. Ask for each answer to be linked to equipment documentation, cell drawings, and check records. If it cannot be tied to the actual configuration, it remains a claim that still needs verification.
Clarify each party’s responsibilities. Who integrates and checks the complete system? Who keeps the risk assessment and records? Who authorizes changes to the program, load, tool, or layout? What training do people receive to operate, clean, or maintain the equipment? How are operating modes and restart conditions indicated? These questions do not replace the judgment of a competent professional, but they help identify proposals based only on the robot’s advertised capabilities.
A robust acceptance should make the scope of verification clear: model and configuration; task and cycle examined; protective devices; operating modes; tests performed; remaining limitations; and conditions that require the system to be reviewed. Keep documentation accessible to people who operate and maintain the installation. If the activity changes, a component is replaced, or an incident or repeated fault occurs, review whether the measures remain adequate. Useful evidence is specific to the application, identifiable, and consistent with the machine being commissioned.
Limits of this guide
Standards, their adoption, and legal obligations may vary by country, sector, date, and the machine’s circumstances. The cited EUR-Lex source summarizes the European machinery-safety framework, but it does not by itself resolve which requirements apply in each case. Confirm the applicable legislation and current standards before designing, integrating, or accepting an installation.
This guide is a framework of questions, not a risk assessment, legal opinion, or certification. It does not provide universal distances, speeds, or biomechanical limits. The practical conclusion is narrower: suitability for working near people must be justified for the specific system and task, with documentation and checks that match its configuration. If that evidence is missing, the product label cannot replace it.