Patent Application
20240031025
The present invention relates to enabling data exchange between formwork panels used in building constructions. In particular the present invention relates to a formwork panel to a method for operating a master light hub, to a method for operating a slave light hub, to a system for light-based signal exchange between our plurality of formwork panels and a respective protocol for implementing the data exchange.
When building constructions, typically, formwork panel structures are used, to be filled with concrete in a subsequent processing step. For this purpose, the formwork panels have to be aligned to each other to build a wall-like structure. It is possible to connect a plurality of such formwork panels, each adjacent to each other in both, the vertical and the horizontal direction.
In the process of construction, it is necessary to exchange data with the system on site. For instance, a user, monitoring the construction process, working at secondary computer system, wants to know, which particular formwork panel has already been positioned in the formwork structure and placed adjacent to which other and which particular another formwork panel still needs to be erected. Further, it would be helpful to have information on e.g., how long the panel is already in use in the particular structure. In particular, it would be helpful to have a measure on how much time the individual panel was stored compared to how much time it has been in use. Also, the physical state of the materials, e.g., hardening of the concrete, would be of interest to improve the quality of the constructional process. Moreover, it would be helpful to get the possibility to provide data to each of the particular form work panels, for instance for instructing them to execute specific functions (for instance to acquire additional sensor data or to transmit specific control data to other panels).
In state-of-the-art systems, the formwork panels did not comprise any electronics so far. Thus, up to now it was not possible to transmit data to/from the formwork panels.
Further, in such settings, typically, several electronic systems are used, like for example control units for controlling a crane for positioning the formwork panels, position detection systems, mobile phones, used by the workers et cetera. Therefore, a radio-frequency-based signal transmission is susceptible to faults and has a risk of a bad signal to noise ratio. The signals could even be manipulated.
Moreover, since a huge amount of such panels are to be used in building constructions, production costs should be kept as low as possible. Thus, it is necessary to provide a solution with low costs and which is not dependent on requirements and/or standards which need to be fulfilled when using radio-frequency-based (RF) signal transmission. So, panel to panel communication should not necessitate RF-based signal transmission. Further, it would be beneficial to have an autonomous system with respect to power supply.
In particular it would be beneficial to provide an option for signal exchange between the formwork panels used in building constructions and a secondary electronic system, e.g., a monitoring computer at low cost. Moreover, the quality of the signal exchange should be improved. Further, signal transmission should not be susceptible to interference or transmission errors.
An object of the present invention therefore is, to improve known formwork systems and in particular to improve quality of building constructions, using formwork panels.
This object is solved by the subject matter according to the independent claims, in particular by a formwork panel according to claim 1, a method for operating a master light hub according to the independent claim 5, a method for operating a slave light hub according to independent claim 12 and a system according to claim 14.
According to a first aspect the invention relates to a formwork panel used for building panel constructions, comprising:
With this solution, the formwork panels may be made “smart” and may be addressed in a digital form to send and/or receive data. Light hubs serve for transmission of digital and/or analog data. The signal transmission is light-based and thus completely safe and not susceptible to transmission errors or to external manipulations (as a RF based transmission would be). Formwork panels equipped with the light hub, positioned adjacent to each other in the formwork construction will be able to communicate data between them using light pulses inside the structural members.
In sum, the present invention relates to a system for light-based signal exchange between a plurality of formwork panels. The formwork panels are each equipped with a light hub which serve to transmit light pulses in a light channel inside the formwork panel to the directly adjacent panels. Respective acknowledgment signals are received in order to discover the existence of the other light hubs being present in the constructional setting. All the signals are aggregated in one master light hub which is in data exchange to a main unit, which may serve as gateway to a secondary computer system. The data transmission and/or the signal transmission (e.g., light signals) is executed according to a predefined protocol. Therefore, the protocol may relate to an information exchange for analog signals (e.g., light pulses) and/or to an information exchange for digital signals (e.g., data).
At a building site, typically, there are hundreds or thousands of panels. Installing a unit with radio module, antenna and a battery in all of them would drive tremendous cost. A battery also has a limited life span. With the suggested innovation, production cost is kept at an absolute minimum while also eliminating the battery. The other key feature is that the panels actually know where they are placed in relation to each other In an imagined system with a large number of panels that instead would utilize radio communication between the individual panels there would be no way of determining exactly in what configuration the respective panels are attached to each other since an exact direction to the individual radio transmitter would not be easily determined. Furthermore, such a system would create a significant amount of radio smog.
Light hubs send and/or receive light form directly adjacent light hubs. A master light hub may send and/or receive signals to directly adjacent light hubs, encoding an instruction to propagate the signal (encoding data) to further light hubs and to aggregate corresponding responses to be sent back to the master light hub. In this way, the master light hub may prepare each slave light hub in the system for communication and for unidirectional or bidirectional data exchange.
A formwork panel is a nearly plate like structure which X and Y dimensions are much bigger than a Z dimension. It is made of wood-based material or may be provided as Plywood. Plywood is made of thin veneers, which are glued together crosswise. The fibers, which are thus arranged at right angles, reduce the swelling and shrinking behavior of the board and contribute to the advantageous technical properties of this material. Depending on the type of wood used, multiplex boards can be characterized by their low dead weight combined with good strength values. Coatings and finishes underline or modify the natural appearance of the wood at the same time. The formwork panel may be used as a support structure forming hollow chambers. The formwork panel may form a hollow structure. According to a preferred embodiment of the present invention, the hollow structure is used for light-based signal exchange. Usually, the formwork panel is used as module in a composite of a plurality of formwork panels by erecting a panel construction, which may be filled with concrete in a later step.
A light channel is formed in the hollow structure for light exchange or light-based signal exchange directly in the formwork panel. Alternatively, or cumulatively, the light channel may be at least in part implemented as light carrier(s) such as plastic and/or glass fibers within the formwork panel and in particular within the hollow structure. In case the hollow structure and a light carrier are used, corresponding optical coupling devices are provided as well. In specific embodiments, the light channels may be angled, due to the angled positioning of the formwork panels. In order to make sure, that light still can be transmitted in the light channels, further optoelectronic devices may be used, like light pipes. Light pipes are optical components used to transport light from a light source set, in particular a board-mounted LED set, to the target point where the light is required (adjacent light hub). They give greater flexibility of light distribution, allowing to change the position of your LED light without changing the location of the LED itself. Most LED light pipes are panel mounted or press fit, making them easy to install. Further, Fresnel lenses may be used.
A hollow structure is a structure within the formwork panel and may define a three-dimensional passage or hollow volume within the formwork panel, in different forms, e.g., as a cylindrical structure. The hollow structures and/or light channels are preferably configured to be perpendicular to each other, e.g., there is a hollow structure/light channel extending in the x axis (horizontally) and another hollow structure/light channel extending in the y axis (vertically) of the formwork panel. The two hollow structures and its light channels are intersecting in an area in the middle of the formwork panel. With these two directions (in x axis and y axis), the light hub, positioned at the intersecting area is in signal exchange with the four channels (up, down in the first direction and right and left in the second direction). Other configurations are possible. Preferably, the hollow structure extends over the whole width and/or height of the formwork panel. The hollow structure serves as data carrier for light signal exchange. Preferably, the hollow structures are completely encapsulated within the formwork panel and no daylight may enter. Signal exchange within the hollow structures uses visible or invisible light for communication. Preferably, for panel-to-panel communication (which corresponds to light hub to light hub communication), line-of-sight propagation is used.
The light hub has a rectangular or box-like form with six (6) main surfaces. Four (4) of these surfaces are configured to face into the four light channels (up, down, right, left) and are configured to close and lock up the respective light channel or the hollow structure so that all light signals being transmitted in the light channel are completely absorbed by the light box. This makes sure, that no light signals may by-pass the light hub.
The light hub is positioned or inserted in the hollow structure, in particular at the crossing of the light channels of the formwork panel. The light hub is configured such that its dimensions nearly corresponding to the ones of the hollow structure or light channel in which it is inserted. The light hub needs to block incoming light in one direction. When the light hub is inserted in the formwork panel it should totally block the hollow structure. For this purpose, soft plastic may be used in the back.
A light hub is an electronic module, in particular a microcontroller-based unit. The light hub may be provided as embedded device. The light hub has light transmission capabilities (data exchange via light). The light hub is configured to send light pulses according to a pre-defined protocol to other, in particular adjacent, light hubs in other (adjacent) panels. The light hub is further configured to receive light pulses from other, in particular adjacent, light hubs in other (adjacent) panels. The microcontroller is configured to generate light pulses according to a pre-defined protocol for encoding panel data. A light hub may be configured to act in two different roles: as master light hub or as slave light hub. The master light hub serves as interface to the main unit, whereas the slave light hubs do only provide light-hub-to-light-hub communication (or panel to panel communication) and do not interface with entities outside of the panel structure.
Generally, any light hub has the technical capability to become a master light hub when a main unit is attached or for example when the system is idle and one of them on its own initiative decides that it is most suitable to begin collecting data. At least four surfaces of the light hub are configured for light signal exchange (when used as slave light hubs). Usually, however five surfaces are configured for light signal exchange for including the signal exchange to the main unit, in case the light hub is used as master light hub and the respective signal exchange between the master light hub and the main unit should also be based on light transmission.
The light hub is configured for light-based transmission. The communication will consist of light pulse trains timed with a certain clock frequency, for example 50 Hz. For every time unit one bit is communicated. For example, an LED being on would signify a binary one (1) and the LED being off would signify a binary zero (0).
In a preferred embodiment, a so-called Manchester code (also known as phase encoding, or PE) is used. This is a line code in which the encoding of each data bit is either low then high, or high then low, for equal time. It is a self-clocking signal with no DC component. Consequently, electrical connections using a Manchester code are easily galvanically isolated.
In another preferred embodiment, a cyclic redundancy check (CRC) is used. This is an error-detecting code commonly used in digital networks and storage devices to detect accidental changes to raw data. Blocks of data entering these systems get a short check value attached, based on the remainder of a polynomial division of their contents. On retrieval, the calculation is repeated and, in the event the check values do not match, corrective action can be taken against data corruption. CRCs can be used for error correction.
CRCs are so called because the check (data verification) value is a redundancy (it expands the message without adding information) and the algorithm is based on cyclic codes. CRCs are popular because they are simple to implement in binary hardware, easy to analyse mathematically, and particularly good at detecting common errors caused by noise in transmission channels. Because the check value has a fixed length, the function that generates it is occasionally used as a hash function.
Usually, the formwork panel is already equipped with a light hub, when being erected. However, for providing a more flexible system, it is also possible to have the light hubs exchanged during the system's usage. Thus, it is possible, to have a formwork panel within the building construction with a first light hub being integrated in the formwork panel and to take this first light hub out of the structure and replace it by a second light hub, e.g., for providing alternative or additional capabilities of the light hub. In this context, for example, other or additional sensor data may be processed. Also, another type of protocol may be provided to the light hub by changing the modular sensor attachment and/or possibly by installing a new software package for processing the other or additional sensor data.
Generally, the light hubs are modular and may be replaced during the systems operation, and in particular even after the formwork panel has been erected. A light hub can easily be detached from and attached to the formwork panel, using a screwdriver to manipulate a locking mechanism. Once removed, a special tool can be used to create a small opening in the formface within the panel through the opening the light hub was mounted in. Preferably, every light hub is attached in the formwork panel such that there is an inspection access, e.g., to replace modular structures on the light hub, like e.g., accumulators or batteries, if necessary or to replace the whole light hub.
Further, the light hub may be equipped with a modular sensor attachment or unit. The modular sensor attachment can be of different types, such as a temperature sensor, a pressure sensor, ultrasonic sensors, or any other type of sensor to be used in the construction. With the modular sensor attachment attached to the light hub it can again be fitted to the formwork panel so that its modular sensor attachment protrudes through the form face inside the cavity that will be poured with concrete in order to acquire sensor data of different types. The modular sensor attachment will then extend the already existing functionality of the light hub so as to measure e.g., properties of the hardening concrete utilizing the light hub as a means to transfer data to a secondary system using light signals inside the construction system (panel-based system), to be possibly transmitted over several hops (jumps) or nodes (here: light hubs).
A light source set is an electronically controllable unit for emitting light. The light source may preferably be a set of LEDs. Alternatively, or cumulatively, the light source may be a laser for emitting coherent light. The set of light sources may be distributed over four of the six surfaces of the cuboid structure of the light hub, namely the four ones, facing the light channels. In case an optical transmission is to be executed between the master light hub and the main unit, the set of light sources and the set of light and receivers is positioned on the front side of the light hub as well, for communication with the main unit.
A light receiver set is an electronically controllable unit for receiving light. The light receiver may in particular and preferably be a phototransistor in order to get fast rise and fall times. Alternatively, or cumulatively, a photo diode or another type of semiconductor device that converts light into an electrical current. In particular, a combination may be used in order to wake the microcontroller from its sleep mode in the wake mode.
The light source set (emitter) and the light receiver set are controlled by the microcontroller according to a predefined interaction process or protocol. For this purpose, a specific type of corresponding emitters and receivers might be used and activated. The interaction process may be based on transmitting or exchanging pulses of light according to a predefined protocol. In a preferred embodiment the system may be used with filters, provided in the formwork panel structure. For example, a first filter may be selected for transmitting panel data, e.g., indicating a first angle which is enclosed between the two panels (e.g., indicating, that the formwork panels are erected with an angle of 120°). Alternatively, or cumulatively, the protocol defines segments for transmission of various panel data. Thus, it may be defined to transmit a first segment which may be selected for transmission of the unique identifier of the respective formwork panel and a second segment for another type of panel data, like sensor data, e.g., temperature, acquired locally at the panel. So, within the system, it can be detected and identified which sensor data has been acquired on which panel. Moreover, a timer may be provided, so that all panel data comprise a time stamp. So, it also can be deduced, when the panel data have been detected. All data is aggregated on a master formwork panel, which serves as communicator port or interface to the central main unit, being temporarily attached to the master formwork panel.
The microcontroller comprises a processing unit for executing a software for controlling signal exchange and storage of data. The light hub usually comprises an A/D-D/A converter for converting light signals or impulses into digital signals, which may be stored locally and transmitted externally. Each light hub may preferably comprise a memory for storing digital data. In particular a registry is used to store digital transmission data relating to any of the four directions. The memory may also be configured to store at least one program for controlling exchange of panel data. The microcontroller may optionally comprise other units. The microcontroller is coupled to the light source set and the light receiver set for controlling their operation.
Panel data are data, being panel specific or panel internal. Panel data characterize or represent the formwork panel in a digital form. Panel data typically differ from panel to panel. Further, panel data differ over time. Panel data comprise a unique identifier of the particular panel. Panel data may comprise other data types, like status data or path data or position data. Status data refer to a physical status of the formwork panel. Status data may comprise data acquired by a set of formwork internal sensors, like temperatures sensors, humidity sensors, pressure sensors and the like and thus comprise temperature data, humidity data, pressure data etc. For each of the different status data types a type specific protocol definition or structure is provided for conversion of the panel data in light pulses for data exchange. Panel data may comprise usage data (defining, how old the panel is), time in use (defining how long the panel is already in use within the building construction), time stored (defining how long the panel has been stored in a stock without use). Panel data may comprise vibration data, audible data and/or solar radiation. Solar radiation data refer to power supply from the photovoltaic panel. Solar radiation data may be an indication of the energy which is provided locally on the panel, i.e., on the light hub. All energy data of all panels may be used to balance the energy level of the whole system. Further, the panel will keep track of its state, being active or dormant.
Data exchange between the formwork panels is executed by means of the light hubs, integrated in each panel. Data exchange is exclusively light based. No electrical signals need to be exchanged.
Data exchange between the master light hub of the formwork panel and a main unit may preferably be based on light, too. Then, the locally stored digital data on the master light hub are to be converted again back into light signals. The protocol for the signal exchange between the master light hub and the main unit may be a second protocol. The second protocol may be identical to the first protocol, used for panel-to-panel communication (light hub to light hub communication, respectively). The light-based signal exchange has the advantage that the connectors are less expensive and cannot break. Alternatively, or cumulatively, data exchange between master light hub and main unit may be executed by another temporary or non-permanent interface (electric connector or plug-in, e.g., like USB etc.).
The interface between master light hub and main unit may also be USB or specific electrical connectors for digital data exchange.
Preferably, the light hubs, in particular the slave light hubs, are supplied with power by means of using a photovoltaic cell (PV cell) at the outside of the formwork panel for providing voltage which may be harvested in an accumulator, capacitor and/or supercapacitor. Thus, energy supply is provided locally on the light hubs. There is no need to provide cables for energy supply. Alternatively, or cumulatively, the light hub may comprise a battery for power supply. Alternatively, or cumulatively, energy harvesting devices may be used in the light hub to provide energy locally, which may be based on e.g., thermal energy, wind energy, salinity gradients, vibration-based methods, and/or kinetic energy.
In a preferred embodiment, the light hub, in particular the master light hub, may be provided with photovoltaic energy by using light sources, provided in the main unit when the main unit is attached to the master light hub. For this purpose, the main unit may be equipped with e.g., a set of light emitting diodes (LEDs). The surface of the formwork panel at the intersecting area is therefore made of translucent material, e.g., plastic material, for enabling light transmission, so that the master light hub may charge with energy (light) from the main unit.
According to a preferred embodiment, the light channels, in particular the hollow structures are extending over the complete width and height of the formwork panel.
Typical sizes of a formwork panel may be several meters in width and height, forming a flat cuboid structure. A typical formwork panel has a height of 3.6 m and á breadth of 2.7 m. Smaller panels have a height of 0.15 m and a breadth of 0.05 m. The hollow structure may have a diameter of 100 mm to 670 mm. Other dimensions are possible.
According to another preferred embodiment, the light hub may be implemented as slave light hub or as master light hub, wherein the slave light hub is configured to communicate exclusively via light pulses with other light hubs and wherein the master light hub is configured to aggregate all data from all slave light hubs and to communicate with a main unit, being non permanently attached to the master light hub.
According to another preferred embodiment, the protocol defines a signal exchange between the network nodes (in particular the master light hub, the slave light hubs, the main unit and optionally a secondary computer system) an defines how to convert the panel data and in particular different types of panel data in light pulses and vice versa.
According to another aspect the invention relates to a method for operating a master light hub (master method) for signal exchange between a plurality of formwork panels as described above, comprising the steps of:
The response is a locally stored data structure, e.g., a registry with light hub specific entries. The response may be transmitted to the main unit as a digital signal, preferably prepared for digital data transmission (e.g., compressed). The response may also be converted back to light signals to be transmitted to the main unit.
According to a preferred embodiment, a fallback mechanism is applied in the system and methods according to this solution. The fallback mechanism assures that each panel first and foremost creates a record of his immediate adjacent neighbors or surrounding before executing any other function and in particular before issuing a discovery procedure. This helps to have a backup of the data, already gathered, even if one or more panels run out of power and may no longer be used for transmitting data.
If a beacon procedure has been executed before and was successfully finished, in the discovery procedure, new data may be exchanged between the light hubs. In the beacon phase only the unique identifier of the respective light hub needs to be exchanged, whereas in the discovery phase additional data, e.g., sensor data and others may be exchanged, too.
Thus, the beacon procedure serves as a handshake to make sure that receiving light hub is existent on the other and of the communication channel.
In another preferred embodiment, the beacon procedure may also be used to try different wavelengths for signal transmission (transmission frequencies), in order to find the best SNR (signal to noise) ratio. This helps to improve quality and may take into account the specific settings of the constructional site (for instance disturbing daylight, entering the hollow structure, a multitude of optoelectronic devices, including filters, for transmitting light in angled light channels etc.). Particular embodiments relate to providing a set of light sources with different wavelengths.
The light pollution in one direction could be completely different than in another. The beacon is unique for the direction (light channel). It might also happen that an older panel is found by the beacon in one direction and a newer by the beacon in another direction. The light hub would then adapt to use the light frequencies, power and protocol version needed in each individual direction. The system knows in what direction light is received and sent (and in which wavelength) and thus the system knows in what direction it is communicating since the respective emitters and receivers are physically separated in each direction, in particular one set in each direction is addressed in the software by a variable d (for direction).
Providing different wavelength light sources commonly or correspondingly on all sides of the light hub, may be used for reducing the effect of the light pollution entering the hollow structure, so that light is emitted in frequencies not found in the pollution to enhance signal to noise ratio as an advantageous technical effect in the signal transmission
The predefined protocol may be defined in a configuration phase and before implementing the light hubs within the light channels, in particular with the hollow structures. The protocol may be updated at a server side and provided by a separate data transmission channel (e.g., RF based, via WLAN or another type of wireless network connection) to the light hubs. According to a preferred embodiment, firmware updates may be distributed to the formwork panels. This may be done, when the system has completed a so-called path functionality (which will be described in the detailed description) and there is an abundance of power they will start an update process using the latest firmware found on a panel in the network.
Another way would be to remove the light hub from the formwork panel or to remove a front cover of the formwork panel covering the light hub and temporarily plug-in a cable or another connector to re-flash the microcontroller (e.g., MCU) from a computer, programmer or maybe the main unit.
The protocol may comprise a wakeup signal exchange, indicating that the respective panel (identified via its unique identifier) is there and is integrated in the formwork panel structure, erected so far. The wake-up may be implemented using discrete components. The protocol may use a beacon signal. During the beacon, the sending light hub will burst full power for a set amount of time. This will be enough to charge a small capacitor through a network of resistors finally triggering a pulling of a reset pin on the microcontroller—in effect waking it up. The protocol may comprise a segment for encoding how much power is left on the light hub, indicating the necessity of power supply. The protocol may also comprise additional segments, encoding other types of panel data, in particular, sensor data, acquired locally at or in the respective formwork panel (e.g., temperature, chemicals inside the formwork panel, pressure, deflection and other physical signals).
According to a preferred embodiment, the master method further comprises:
According to a preferred embodiment of the master method, the protocol may be based on a challenge response protocol, wherein generated light pulses serve as challenge light pulses and are sent by the light source set to slave light hubs in other formwork panels, which are acknowledging receipt of the same by sending response light pulses back.
According to a preferred embodiment of the master method, emitting is done in four directions, in particular one at a time, and wherein the sequence of light pulses is specific for four directions and may comprise a direction identifier.
The sequence of light pulses may be sent from each light hub in four directions, in particular in an upward, downward, right and left direction. For this purpose, the light hub has a box-like shape with six (6) surfaces, wherein at least four of them are configured with light emitters and receiver respectively for sending/receiving light pulses in/from the light channels, in particular, the hollow structure, which the respective surface of the light hub box is facing at. Only one light hub, namely the master light hub, is configured to transmit light in an additional direction which is in Z direction, being perpendicular to the X and Y direction of the formwork panels extension. The master light hub is configured to transmit light to and/or from the main unit in time phases, during which the main unit is attached to the master light hub. As already described above, any light hub has the technical capability to become a master light hub when a main unit is attached or for example when the system is idle and one of them on its own initiative decides that it is most suitable to begin collecting data. This could for example be “IF Idle for more than x hours AND there is no adjacent panel to the left or down (that is the light hub is in the bottom left corner) THEN become self-appointed master”.
According to a preferred embodiment of the master method, the method comprises:
The method is configured to send the “wake-up” burst in effect waking-up the other light hubs (dormant->awake state). Then, the light hubs may interchange a “Is any one listening?” signal exchange and then exchanging information relating to: “What version of the protocol should we use?”. After this, the light hubs may proceed with testing frequencies and local power supply. If this has already been established during earlier beacons (exchanges in earlier sessions) the light hubs may resume using that “earlier” (stored) data until something fails.
The discovery procedure or function is only focusing on directly adjacent light hubs (neighbours). The path function will identify all slave light hubs in the network of light hubs.
According to a preferred embodiment, the beacon procedure comprises the steps of:
According to another preferred embodiment, the method may comprise adjusting frequency and/or power of the emitted sequence of light pulses, in particular of the beacon signal, to optimize both of a signal to noise ratio and an energy consumption. With this, the frequency and/or power are adjusted such that as less as possible power will be consumed by providing a sufficient signal to noise ratio. This adjustment step is preferably performed for the beacon signal.
According to another preferred embodiment, executing the discovery procedure by the master light hub comprises executing a path function, comprising:
According to another aspect the invention relates to a method for operating a slave light hub (slave method) for signal exchange between a plurality of formwork panels as described above, comprising the steps of:
According to a preferred embodiment of the slave method, the transfer function considers actual power resources of the light hub. So, the change from awake to sleep/dormant state may be in the range of 12 hours or several seconds, depending on the mode of the light hub and its available power.
According to another aspect the invention refers to a system for light-based signal exchange between a plurality of formwork panels used in building constructions to build a panel construction, with:
In a preferred embodiment of the system, the main unit is at least temporarily coupled to a secondary electronic system via a wireless protocol for data exchange.
The main unit is a separate electronic unit, which may non-permanently attached to the outside of the master formwork panel for the purpose of signal exchange or transmission.
The main unit may comprise attachment means for attachment of the main unit at the master formwork panel (with the master light hub) such that signal exchange may be carried out. The attachment means may comprise a clamp to secure the main unit to the formwork panel so that the back is in direct contact with a master light hub. The main unit provides digital interconnectivity (data transmission) in the direction facing the master light hub by the means of sending and receiving electromagnetic radiation in the infrared frequency range.
For power supply, a large panel with a multitude of photovoltaic cells is provided in order to harvest energy from incoming sunlight mounted by the means of a hinge for direction towards the sun during use. When not in use the panel is collapsed so that it is flush with a main unit body. A rechargeable battery for the storage of harvested energy or from an intermittently connected external power source may be provided, too. Further, the main unit is equipped with a radio transceiver and a multiband antenna for digital data two-way radio communication to a secondary system (i.e., the Internet or optionally any other compatible system such as a Data Acquisition System). Optionally, connectors may be provided for temporary optional external power supply or optional serial data communication to any other compatible device, also including a display device, which may be used for reading sensor or other panel data locally on site. Moreover, persistent internal memory, high order data management and rudimentary user functionality for example using buttons or a graphical display, as mentioned above, may be configured.
According to a first embodiment, signal exchange may be based on light pulses only. In a second embodiment, signal exchange is based on a wireless protocol, being implemented by using radio frequency (RF), like being based on IEEE 802.11 standard. Here, RF-based near field communication may be used (NFC). Alternatively, wireless personal area networks (WPANs) may be used to connect the master light hub with the main unit (within a relatively small area, when being attached). For example, Bluetooth, ZigBee and/or other Wi-Fi integrations or other data exchange architectures may be used. Alternatively, a wired connection may be used, like a USB interface in one of different generation types, e.g., USB-1 to USB-4.
The attachment means for attaching the main unit to the master light hub may be based on magnetic fasteners. The attachment means may be implemented as plug-in connection so that the main unit may be attached to the master light hub by simply clicking in. The main unit is preferably fastened to the panel in two stages—guiding pins and possibly magnets that aligns it perfectly and then by means of a clamping mechanism that firmly secures it in that position
The light hubs are fastened to the panel by the means of spring actuated “hooks” that can be released by using a special tool or a screwdriver.
The main unit may be provided with energy by means of photovoltaic cells, provided on the surface of the main unit. Alternatively, or cumulatively, the main unit may comprise a local battery and/or may use different types of energy harvesting methods, mentioned above.
According to a preferred embodiment, the interface between the master light hub and the main unit is bidirectional and configured to send and/or receive data.
Usually, mainly signals will be sent from the master light hub to the main unit. The main unit, in turn, may be connected to a secondary computer system (e.g., a server with a user interface so that a user may monitor the whole construction site with the actual and past status of the formwork panel construction. So, the user may identify, e.g., at a remote site, which panel is attached to which other panel by also providing position information. On the secondary computer system, a building information model may be run for planning and visualizing the status of the constructional site.
In specific application, signals may be sent from the main unit to the master light hub and via the master light hub to connected slave light hubs. These signals may encode control signals, e.g., for activating/deactivating certain sensors and/or for updates of a protocol.
By providing a light-based or optical signal exchange between the panels, the technical advantage is that signal exchange is completely independent of RF standards. Further, the system is not susceptible to radio noise. No cables, no antennas are needed of signal exchange.
According to another preferred embodiment, the master light hub communicates with the main unit and/or with the slave light hubs via light pulses.
The interface between the master light hub and the main unit may preferably be an optical interface. However, alternatively, the interface may be another wired or wireless interface. The interface between the slave light hubs is exclusively based on light signals. The interface between the slave light hubs and the master light hub is also exclusively based on light signals.
The interface between master light hub and main unit may also be USB or electrical connectors for digital data exchange.
As mentioned above, the master light hub may be supplied with power by the main unit or by an autonomous local power supply system (e.g., photovoltaic cells) and/or may be equipped with a battery and/or wherein the slave light hubs may be supplied with power locally by an autonomous power supply system and/or may be equipped with a battery.
According to another preferred embodiment, at least one of the formwork panels has a corner structure with a particular angle and wherein the system further comprises reflectors and/or light filters, attached in the light channels of the formwork panel in order to provide light exchange also in angle structures.
According to another preferred embodiment, the signal strength of the transmitted light signals, exchanged between the light hubs is determined and processed and/or wherein filters are placed within the light channel, for activating remedy measures in case at least one of the formwork panels is not equipped with a light hub or one slave light hub has not sufficient power. In some formwork panel structures, so called spacer blocks or other passive members may need to be integrated, in which no light hub may be integrated, because e.g., the width is too small. Then, the length for signal transmission is longer and correspondingly the signal strength is lesser. Therefore, the signal strength is captured in order to deduce the use of passive formwork panels (e.g., spacer blocks and the like). So, the user may know, where (position information) and how many passive members (panels without a light hub) are used in the structure.
Further, filters may be provided instead of a light hub. The filters may be configured specifically, e.g., to filter out certain wavelengths of the transmitted signals. For example, in case of a red-light filter is used, the red light is received with significantly higher signal strength than the other colors. With this information, it can be identified, which passive element is positioned and where.
Further features and advantages will become apparent with the detailed description of preferred embodiments in reference to the figures.
The present invention relates to providing a reliable signal exchange between a set of formwork panels, used in building constructions, which may be used to create a temporary structure that can be filled with concrete, in effect creating a permanent concrete solid, once the panels are removed. Further, signal transmission should also be possible to an external computer system to exchange digital (or analogue) data. Generally, signal transmission should be bidirectional.
Preferably, the signal transmission is an optical transmission and based on light signals. This has the major technical advantage, that signal transmission is not susceptible to disturbances and failures and thus provides a high degree of reliability. Further, the costs for producing such formwork panels with the electronics inside, may be kept as low as possible.
The light hubs LH sleep most of the time to preserve the available energy in the capacitor and/or battery. When awake, they can be either INACTIVE (alone and not used), ACTIVE (adjacent to another), DISCOVERY (trying to get to know the closest neighbor in each direction), MASTER (having a Main Unit docked on top), PATH (finding the paths to as many neighbors as possible only limited by available power).
They wake up when a timer (tmr: timer) tmrBeacons overflows after a set amount of clock cycles (the SLEEP time), which may be preconfigured. According to a preferred embodiment, the timer may be adapted according to a detected power signal, indicating the actual power supply of the respective light hub LH.
At each tmrBeacon overflow they store how long time they slept INACTIVE (DORMANTCOUNTER) or any other mode (ACTIVECOUNTER). This serves as a record over how much time they have spent mounted on a site and how much time they have been stored and haven not been used.
The SLEEP time is a function of the MODE, current Power level and the results of earlier activities. The main idea is to preserve as much power as possible for data transmission.
The first thing a light hub LH will do when it wakes up is to send out a beacon—basically a burst of light with rudimentary handshake functionality.
If it finds a neighbor (adjacent light hub LH) answering its beacon they will initially just share each other's identifying ID.
If a light hub LH gets a Main Unit MU on its back it will switch to PATH mode and try to map the whole network by spreading the PATH mode. All light hubs LH that are in PATH mode will explore their surroundings.
All path data will ultimately be aggregated at the light hub LH first issuing the PATH mode.
Once path information is available and communications partners are prepared for signal exchange, this can be used to send and receive messages within the network of paths.
The light hub communication is based on four basic functions.
1. Beacon
A light hub LH will signal its presence and try to initiate communication with adjacent light hub's on timed intervals. The Beacon procedure will perform a handshake and prepare both ends for further communication.
The discrete electronics in the light hub is configured such that a beacon can awake the microcontroller from its sleep mode.
2. Discovery
A light hub LH will present its own ID to adjacent light hub's and in turn also store their corresponding ID's.
3. Path
A light hub LH will request data stored in the adjacent light hub's direction registers. Data will be sent in the order of the count. The receiving light hub will automatically add path data corresponding to the source direction onto the path data received. A request of a non-existing count will result in a transferpathRefuse.
4. Send
A light hub LH can send data to another light hub using the ID and path data. The payload of the Send function will be relayed by the light hub's in the path.
Each light hub LH is uniquely numbered during manufacturing. The length of the ID has to be long enough to ensure a total uniqueness of all manufactured light hub's but short enough as to not create to heavy data loads on the system. As an example, an ID with the length of four bytes would enable up to 4 294 967 295 uniquely numbered light hubs.
The unique identifier (ID) is within:
Directions in the system are labeled d and stored in the path information using two bits. To increase readability, symbols are used below.
Example path:
Each light hub LH has four registers, one for each direction (Rn (0≤n≤3)). When an adjacent light hub LH has issued the DISCOVERY the responding light hub LH will in turn issue a DISCOVERY on all other available light hubs LH next to it. When a DISCOVERY has been issued and trickled around in the grid each has the ID (identifier) of adjacent light hub LH's stored on the first position in each corresponding Path Register.
The initial discovery serves as a first mapping and a resort should any light hub LH in the grid run out of power until a full PATH command has been issued.
The first column in the registry is merely an index unique to the individual register. The count is a counter irrespective of direction and common for all four registers—it is based on the CountLOCAL variable. The ID is the unique ID's of light hub's chained in the registry direction.
The path is the actual path data needs to travel in order to reach the corresponding light hub LH. The paths are stored as directions encoded as a two-bit number (0-3).
The registry schematically looks like:
Each light hub LH has four counters, one for each direction (0≤d≤3). When data has been fetched (or skipped) in the corresponding direction the counter is incremented, so that the next initPath can address data not already read. If the light hub LH targeted by the initPath responds with a transferPathSkip the counter is incremented without any other action.
Countd (0≤d≤3) [INTEGER]
Each light hub LH also has a local counter containing the total count of all records (rows) stored in all Rd.
CountLOCAL=ΣRd·RowCount (0≤d≤3) [INTEGER]
Each light hub LH will always be in one and only one MODE, which will be explained below:
1. Inactive
All attempts to beacon adjacent LH's have failed. On each tmrBeacon overflow the DORMANT counter will increase in order to keep a record of how long the light hub has been INACTIVE.
2. Active
At least one light hub LH has answered the beacon. On each tmrBeacon overflow the ACTIVE counter will increase in order to keep a record of how long the light hub LH has been ACTIVE. This will also have an effect on determining how long time that shall pass between each tmrBeaconOverflow.
3. Discovery
The System is in Discovery mode and will thus start to collect the ID's of its immediate neighbours.
4. Master
The light hub LH is designated being master mLH and will be the one that issues the Path function. Only one light hub LH can be master. Normally this happens when a main unit MU is attached to the light hub LH. It would also be possible for a light hub LH that senses that is farthest down to the left to issue this after a set amount of time. This would prepare the system for a later attachment of a main unit MU.
5. Path
The light hub LH has been set into PATH mode since another light hub LH in the system has been assigned master light hub mLH.
The purpose of the discovery function is to establish an initial contact between light hub LH directly adjacent to each other. If one or more light hubs LH should run out of power their closest neighbor will have a record of its presence (backup function) The discovery function will be explained more detailed below with reference to
For embodying signal transmission via light, electronics in the form of so-called light hubs LH are used, which are introduced as small rectangular boxes into all or selected group of formwork panels P. The light hubs LH are exchangeable and replaceable, even after mounting of the formwork panels P.
Based on the example formwork construction, given in
According to a preferred embodiment, the data exchange between the master light hub mLH and the main unit MU is light-based, too. However, in other embodiments, it is also possible to have another data transmission channels, like electrical (e.g., USB, WiFi, ZigBee etc.) or radio frequency-based data transmission. The data gathered on the main unit MU may further be transmitted to the secondary computer system 2C. The data exchange between the main unit MU and the secondary computer system 2C may be other wired or wireless data connection, and may in particular be implemented as radio frequency-based transmission. Preferably, both, the light hub to light hub data transmission as well as the data transmission between the master light hub mLH and the main unit MU is a light-based signal transmission, which in
Proper seal towards the back wall is provided by compressible foam plastic 107. In a preferred embodiment the light hub unit is supplied with energy for operation from the sun shining on a multitude of photovoltaic cells assembled together to form a panel 108 facing outwards from the formwork panel P. At least four surfaces of the light hub LH are facing and engaging with the light channels or with the hollow structures for light transmission. Outbound communication in each of the four directions inside the hollow structure is carried out using light emitted by one or more of a plurality of light emitters, in a preferred embodiment red 111, green 112 and blue 113. Furthermore, inbound communication is detected by a photocell behind a Fresnel lens 114.
As shown in
On the right lower corner of
In another preferred embodiment, it is also possible to provide the main unit MU with a display for user interaction with system by means of the main unit directly on site, i.e., locally at the constructional site. Alternatively, the main unit may transfer the gathered data to an external secondary computer system 2C, as mentioned above.
In
Secondly, data is transferred in both directions using the light emitters and photo cells (109, 110, 209, 210).
In this example, a red reflector 91 is fitted inside the structural member of two formwork parts comprising 90°-degree corner joints. A light hub LH in the panel to the right of the corner tries to communicate to the panel next to it. As a part of the protocol a test procedure is carried out whereby only individual colors of light are emitted, for example first red, then green and last blue. The light hub LH receiving this, will report back the power input of each individual light pulse. The test is carried out in both directions and the result is compared. If the conclusion is that the green and blue light pulses were both significantly less powerful than the red ones, this leads to the conclusion that a reflector mainly reflecting red light is placed between said two light hubs. This information is then made available to the rest of the network comprised of all other panels. Corners with other angles with other reflector coloration can be identified in an identical way.
Further, a spacer element may be positioned between two formwork panels P, shown in
n=the pointer to the next unread entry in the adjacent LH
The Data counter keeps track of which entry is next to be read thus n will be set to Countd+1 for this initPath try.
ID0=The ID of the Master LH that initially started the Path
If successful, the light hub LH1 will store the ID and path of as many light hub's n as possible incrementing n each time.
All units that have been requested a path will in turn be set in path mode and path data will be aggregated with subsequent transferPath calls until the adjacent light hub responds with a transferPathRefuse.
Infinite loops are avoided.
The first light hub LH that initialized the transferPath provides its own ID in the request (ID0). Adjacent light hubs will respond with transferPathSkip if the requesters ID or ID0 is found on the requested Rd:n or later.
Step 1:
Formwork panels with light hubs are placed according to the earlier example. Although not a prerequisite in this example the DISCOVERY has been issued and has been fully propagated in effect creating redundant information on each panel. A main unit MU is attached to light hub ID: 02. This has activated the Path function with ID: 02 now being the master of all other panels. Since it now has its power supply secured via the main unit MU it takes an active role to aggregate data from all light hub's in the network. The master light hub mLH will issue an initPath in all directions one at a time, keeping track on the count in each individual direction. The count is incremented for each aggregated ID in that direction. Paths are read until the light hub at the other end responds with a transferPathRefuse. It will then try in the next direction. This will continue with intermittent breaks (sleep periods) in the case the adjacent light hub's all returns transferPathRefuse. At the next overflow of tmrBeacon it will try again to see of additional data is available on the next count in the respective direction.
The signal exchange is possible, even if a light hub (here: ID: 05) has run out of power and is not responding on beacons. This may be represented by:
Step 2:
Light hub ID: 02 is the master and thus initiates the Path functionality. The first direction to attempt is Down but no beaconAck is received in this direction. Next direction to try is left. A beaconAck is received and an initPath is directed to light hub ID: 01 to the left. The count was 0. This entry points back to the sender. light hub ID: 01 responds with a transferpathSkip and also flags for itself that all deeper requests in that direction (deeper to the right) from the light hub to the right (ID: 02) shall be responded with a transferpathSkip since they will pass through the transmission system that made the original request. Light hub ID: 02 increments count to 1 and issues a new initPath. Since a Discovery was already made this attempt is immediately successful. Light hub ID: 01 answered that it had content on count 1, namely ID: 07 in the direction Up (▴). Light hub ID: 02 immediately acknowledges the received data and tries again on count 2. Since light hub ID: 01 was just set into path mode it has not yet had time to aggregate more data. There is no information on count 2. It issues a refusePath. This closes the communication with light hub ID: 02 for now and will force light hub ID: 02 to try in the next direction. The table for light hub ID: 02 shows the content of the direction registers as well as the MODE.
Step 3:
Light hub ID: 02 continues to initiate the Path functionality. Now the direction is to the right. A beaconAck is received and an initPath is directed to light hub ID: 04 to the right. The count is 0. This entry points back to the sender. light hub ID: 04 responds with a transferpathSkip and also flags for itself that all deeper requests in that direction (deeper to the left) from the light hub to the left (ID: 02) shall be responded with a transferpathSkip since they will pass through the transmission system that made the original request. Light hub ID: 02 increments count to 1 and issues a new initPath. Since a Discovery was already made this attempt is immediately successful. light hub ID: 04 answered that it had content on count 1, namely ID: 05 in the direction Right (). Light hub ID: 02 immediately acknowledges the received data and tries again on count 2. light hub ID: 04 answered that it had content on count 2, namely ID: 06 in the direction Up (A). Light hub ID: 02 immediately acknowledges the received data and tries again on count 3. Since light hub ID: 04 was just set into path mode it has not yet had time to aggregate more data. There is no information on count 3. It issues a refusePath. This closes the communication with light hub ID: 02 for now and will force light hub ID: 02 to try in the next direction. The table for light hub ID: 02 shows the content of the direction registers after the transactions exemplified above.
Step 4:
Light hub ID: 02 continues to initiate the Path functionality. Now the direction is to up. The process described earlier is repeated and light hub's ID: 07 as well as ID: 06 are added to the register for the Up direction. Since the Path functionality is now trickling out in the System light hub ID:07, ID: 04 and now also ID: 03 is now also aggregating data on their own. If the ID of the light hub originally issuing the Path functionality (ID0) is addressed (count) or if the address (count) refers to the sender the responding light hub will always issue a transferpathSkip. This prevents an overload of redundant data. The table for light hub ID: 02 shows the content of the direction registers after the communication in the Up direction described above.
Step 5:
The Path functionality originally activated by light hub ID: 02 trickles out in the network. This has the effect that all panels start to aggregate Path data. In the meantime, light hub ID: 02 resumes to a passive state for a short while. If the ID of the light hub originally issuing the Path functionality (ID0) is addressed (count) or if the address (count) refers to the sender the responding light hub will always issue a transferpathSkip. This prevents an overload of redundant data. By now light hub ID: 07 has collected data from the full row of light hub's all the way to light hub ID: 06 but not further. Light hub ID: 01 issues the Path functionality in the direction up and receives new data that was not available earlier—namely the ID's and paths for all panels up until ID: 08.
Step 6:
Light hub ID: 02 now again issues the Path functionality in each direction and receives the new data that was not available earlier—namely the ID's and paths for all panels up until ID: 08 with the corresponding paths to reach light hub ID: 03 and ID: 01 respectively. At the same time the Path function trickles farther out in the System finally reaching the most distant light hubs.
Step 7:
Light hub ID: 02 will continue to probe the adjacent light hub's for any new data but the System is now fully determined and all issued initPath's will be refused. Note that even though light hub ID: 05 only achieved to transfer its ID on the initial Discovery it is still successfully mapped in ID: 02's registers.
The registry entries look like:
Send function:
The purpose of the Send function is to transfer data of any kind between light hub's using the Path data stored. The Send function tries to send the data using the shortest path possible. Since the Payload can be any arbitrary type of data advanced messaging would be possible. A part of the Payload could for example be a message header containing the Sender ID and a flag if an acknowledgement of received message is expected. When the receiver gets the message, it will return a new message with a Message received flag in the corresponding header.
). Light hub ID: 02 will initSend in direction 2 (Right) to ID: 04. The same algorithm is applied jump by jump until the message reaches its destination.
Generally, the result, which is being generated, may be provided on an output interface, e.g., on a display means or may be provided as an acoustic output. The result encodes all the aggregated data on the master light hub mLH. In particular, the result encodes:
As already mentioned above, the signal exchange between the main unit MU and the light hubs LH is bidirectional, so that also instructional data may be sent to a specific formwork panel P. The instructional data may for example trigger the light hub LH on the respective formwork panel P to execute a specific function or to change a state [dormant/awake] or role.
The secondary computer system 2C may operate in a networked environment which defines physical connections to one or more remote computers. The remote computer may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and may include many or all of the elements described above. The physical connections include a local area network (LAN) and a wide area network (WAN), an intranet and the Internet.
Wherever not already described explicitly, individual embodiments, or their individual aspects and features, described in relation to the drawings can be combined or exchanged with one another without limiting or widening the scope of the described invention, whenever such a combination or exchange is meaningful and in the sense of this invention. Advantages which are described with respect to a particular embodiment of present invention or with respect to a particular figure are, wherever applicable, also advantages of other embodiments of the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20213491.2 | Dec 2020 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2021/085228 | 12/10/2021 | WO |
