A system is defined by the relationship between parts
A motor can move. A controller can send a command. A sensor can detect a condition. None of these components alone defines the architectural experience. The system appears when these details are coordinated around one requirement.
Motion: the physical layer
Motion includes motors, actuators, drives, rails and mechanical transmission. This layer answers the physical questions: what moves, how far, at what speed, under what load and through what path?
Control: the command layer
Control determines how the movement is addressed and operated. A controller, receiver, interface or gateway decides whether a user operates one opening, a group, a floor or an entire project. RF, RS485, KNX and BMS are examples of technologies that can sit within this layer depending on the project architecture.
Intelligence: the behaviour layer
Automation, sensors, schedules and scenarios add behaviour. Instead of waiting for an individual command, the system can respond to time, user presets or other project inputs. This is where the technology starts to feel integrated into the space rather than attached to it.
Architectural systems are the visible result
Skylights, pergolas, smart film, side channels, roller systems and custom movement applications are where the technology becomes visible. They are not separate from the stack below them; they are the final expression of it.
Why this matters during design
If the project starts with the visible product only, important questions can appear late: Where does power come from? Which controller is compatible? How are zones grouped? Can the system connect to BMS? Is there service access? Starting from the system architecture makes these decisions earlier and reduces coordination risk.
The specification should become more detailed as the project develops
At concept stage, the project may only need to define the architectural behaviour. During design development, the team can select the movement method, control architecture and integration approach. Product codes and technical specifications should appear later, when the system logic is already clear.
This progressive approach is the core of NERVEN’s technology positioning: architecture first, then system, then technology, then engineering detail, and finally the product and its specification.