LIGHT BUS IN BUILDING CONSTRUCTIONS WITH FORMWORK PANELS

Abstract

The present invention relates to a system for light-based signal exchange between a plurality of formwork panels (P). The formwork panels (P) are equipped with a light hub (LH) which serve to transmit light pulses in a light channel inside the formwork panel (P) to the directly adjacent panels. Respective acknowledgment signals are received in order to discover the existence of the other light hubs (LH) being present in the constructional setting. All the signals are aggregated in one master light hub (mLH) which is in data exchange to a main unit (MU), which may serve as gateway to a secondary computer system (2C). The data transmission is executed according to a predefined protocol.

Claims

1. A formwork panel (P) used for building panel constructions, comprising: A hollow structure, which is used for forming light channels within the formwork panel (P), extending in at least two axes, wherein the at least two axes are configured to have an intersecting area; A light hub (LH), positioned at the intersecting area inside the formwork panel (P), such as the light hub (LH) and in particular its surfaces are facing the light channels, and wherein the light hub (LH) comprises at least a light source set (Iss) and a light receiver set (Irs) and a microcontroller (C), coupled to the light source set (Iss) and the light receiver set (Irs) for controlling operation of the same; wherein each formwork panel (P) provides panel data, comprising a unique identifier (ID); wherein the microcontroller (C) is configured to control operation of the light hub (LH) and in particular the light-based signal exchange to and from at least one other light hub (LH) in at least one other formwork panel (P), placed adjacent to the formwork panel (P) in the panel construction according to at least one predefined protocol.

2. The formwork panel according to claim 1, wherein the light channels, in particular the hollow structures are extending over the complete width and height of the formwork panel (P).

3. The formwork panel according to any of the preceding claims, wherein the light hub (LH) may be implemented as slave light hub or as master light hub (mLH), wherein the slave light hub is configured to communicate exclusively via light pulses with other light hubs and wherein the master light hub (mLH) is configured to aggregate all data from all slave light hubs and to communicate with a main unit (MU), being non permanently attached to the master light hub (mLH).

4. The formwork panel according to any of the preceding claims, wherein the protocol defines how to convert the panel data and in particular different types of panel data in light pulses and vice versa.

5. A method for operating a master light hub (mLH) in a formwork panel (P) according to claim 1 for signal exchange between a plurality of formwork panels (P), wherein a slave light hub is configured to communicate exclusively via light pulses with other light hubs and wherein the master light hub (mLH) is configured to aggregate all data from all slave light hubs and to communicate with a main unit (MU), being non permanently attached to the master light hub (mLH), comprising the following steps, which are executed on the master light hub (mLH): Providing (SM1) panel data with a unique identifier (ID) of the formwork panel (P) locally at the formwork panel (P); Converting (SM2) the provided panel data to a sequence of light pulses according to a predefined protocol and Emitting (SM3) the sequence of light pulses to the slave light hubs in directly or indirectly adjacent formwork panels (P); Receiving (SM4) a sequence of response light pulses from the slave light hubs in response to the emitted sequence of light pulses; wherein emitting (SM3) and receiving (SM4) may comprise the respective panel data; Aggregating (SM5) all received response light pulses and Generating a result (SM6), encoding the aggregated received response light pulses.

6. The method according to the directly preceding method claim, wherein the method further comprises: By the master light hub (mLH): Transmitting (SM7) the generated result to an external unit, in particular to a main unit (MU), being non-permanently attached to a master formwork panel (P), carrying the main unit (MU).

7. The method according to any of the preceding method claims, wherein 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.

8. The method according to any of the preceding method claims, wherein emitting (SM3) 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.

9. The method according to any of the preceding method claims, wherein the method comprises the following steps, which are executed on the master light hub (mLH): Initiating a beacon procedure for performing a handshake procedure for initiating communication with adjacent light hubs and for preparing the master light hub and the respective slave light hub(s) for communication; Initiating a discovery procedure for identifying all directly adjacent slave light hubs and determining their position in each of the four directions as first intermediate result; Initiating a path function for identifying all slave light hubs, in particular, by propagating the path function in the network of light hubs as second intermediate result; Aggregating all intermediate results of the discovery procedure in all four directions and generating a result, which is stored as result data structure in digital form locally in a memory.

10. The method according to the directly preceding method claim, wherein the beacon procedure comprises the steps of: Sending a beacon signal in each of the four directions to each adjacent light hub with a unique identifier; Receiving a response to the sent beacon signal; Storing the unique identifier of the light hub from which an acknowledge signal has been received.

11. The method according to any of the preceding method claims, wherein the method comprises: Adjusting frequency and/or power of the emitted sequence of light pulses, in particular of a beacon signal, to optimize both of a signal to noise ratio and an energy consumption.

12. The method according to claims 9 or 10 or 11, wherein executing the discovery procedure by the master light hub (mLH) comprises executing the path function, comprising the steps to be executed on the master light hub (mLH): sending a unique identifier to the adjacent slave light hubs in each of the four directions; in response: receiving the unique identifiers of the adjacent slave light hubs as response message; storing the response message with an indication of the direction.

13. A method for operating a slave light hub in a formwork panel (P) according to claim 1 for signal exchange between a plurality of formwork panels (P), wherein the slave light hub is configured to communicate exclusively via light pulses with other light hubs and wherein a master light hub (mLH) is configured to aggregate all data from all slave light hubs and to communicate with a main unit (MU), being non permanently attached to the master light hub (mLH), comprising the following steps, which are executed on the slave light hub: Receiving (SS1) a beacon signal from an adjacent light hub; In response to the receipt of the beacon signal: Transferring (SS2) the slave light hub from a dormant state in an awake state; Acknowledging (SS3) the receipt of the beacon signal; Transferring (SS4) the slave light hub from the awake state in the dormant state by applying a transfer function; Receiving (SS5) a discovery signal from an adjacent light hub; Propagating (SS6) the received discovery signal to an adjacent light hub in the same direction until a last light hub in said direction is reached and incrementing a counter locally for each aggregated unique identifier.

14. The method according to the directly preceding claim, wherein the transfer function considers actual power resources of the light hub;

15. A system for light-based signal exchange between a plurality of formwork panels (P) used in building constructions to build a panel construction, with: A plurality of formwork panels (P) according to claim 1, which are to be erected to build a wall-like structure; At least one main unit (MU) for the plurality of formwork panels, which is configured to be temporarily attached to a master formwork panel, wherein one of the plurality of formwork panels (P) is configured as master formwork panel and its light hub is configured as master light hub (mLH), which is configured to serve for signal exchange and as an interface to the main unit (MU) and which is configured to be operated with a method according to any of the method of claim 5 to 11.

16. The system according to the directly preceding claim, wherein the main unit (MU) is a and/or may be at least temporarily coupled to a secondary electronic system (2C) via a wireless protocol for data exchange.

17. The system according to any of the preceding system claims, wherein the interface between the master light hub (mLH) and the main unit (MU) is bidirectional and configured to send and/or receive data.

18. The system according to any of the preceding system claims, wherein the master light hub (mLH) communicates with the main unit (MU) and/or with the slave light hubs via light pulses.

19. The system according to any of the preceding system claims, wherein the master light hub (mLH) may be supplied with power by the main unit (MU) or by an autonomous power supply system and/or may be equipped with a battery and/or wherein the slave light hubs may be supplied with power by an autonomous power supply system and/or may be equipped with a battery.

20. The system according to any of the preceding system claims, wherein at least one of the formwork panels (P) 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 (P) in order to provide light exchange also in angle structures.

21. The system according to any of the preceding system claims, wherein 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 (P) is not equipped with a light hub (LH) or one slave light hub has not sufficient power.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0117] Further features and advantages will become apparent with the detailed description of preferred embodiments in reference to the figures.

[0118] FIG. 1 shows an exemplary formwork panel construction with several light hubs;

[0119] FIG. 2 depicts a schematic representation of a network of light hubs in optical communication connection according to the example construction of FIG. 1;

[0120] FIG. 3 shows a light hub;

[0121] FIG. 4 shows more details of a possible construction of a light hub;

[0122] FIG. 5 is a structural figure for a light hub in form of a block diagram;

[0123] FIG. 6 is a block diagram of a main unit;

[0124] FIG. 7 shows more constructional details of main unit according to a preferred embodiment;

[0125] FIG. 8 shows an attachment of the main unit to a master light hub according to a preferred embodiment;

[0126] FIG. 9 shows a corner structure of the formwork panels with reflectors for signal transmission;

[0127] FIG. 10 is a flow chart for signal exchange by executing a discovery function;

[0128] FIG. 11 is an interaction diagram for signal exchange between the involved lights hubs of the discovery function;

[0129] FIG. 12 is a flow chart for executing a path function;

[0130] FIG. 13 is an interaction diagram for signal exchange between the involved lights hubs of the path function;

[0131] FIG. 14 is a flow chart for executing a send function;

[0132] FIG. 15 is an interaction diagram for signal exchange between the involved lights hubs of the send function;

[0133] FIG. 16 is an exemplary representation of registry entries for an executed send function;

[0134] FIG. 17 is a flow chart for a method for operating a master light hub mLH according to a preferred embodiment.

[0135] FIG. 18 is a flow chart for a method for operating a master light hub mLH according to another preferred embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS WITH RESPECT TO THE FIGURES

[0136] 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.

[0137] 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.

Embodiment(s) for the Protocol

[0138] 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).

[0139] 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.

[0140] 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.

[0141] 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.

[0142] The first thing a light hub LH will do when it wakes up is to send out a beaconbasically a burst of light with rudimentary handshake functionality.

[0143] If it finds a neighbor (adjacent light hub LH) answering its beacon they will initially just share each other's identifying ID.

[0144] 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.

[0145] All path data will ultimately be aggregated at the light hub LH first issuing the PATH mode.

[0146] 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.

[0147] The light hub communication is based on four basic functions.

[0148] 1. Beacon

[0149] 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.

[0150] The discrete electronics in the light hub is configured such that a beacon can awake the microcontroller from its sleep mode.

[0151] 2. Discovery

[0152] A light hub LH will present its own ID to adjacent light hub's and in turn also store their corresponding ID's.

[0153] 3. Path

[0154] 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.

[0155] 4. Send

[0156] 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.

[0157] 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.

[0158] The unique identifier (ID) is within: [0159] 0<=4 294 967 295 [0160] or in hexadecimal [0161] 00 00 00 00=>FF FF FF FF.

[0162] Directions in the system are labeled d and stored in the path information using two bits. To increase readability, symbols are used below. [0163] d (0n3) [0164] where [0165] n=0 Down [0166] n=1 Left [0167] n=2 Right [0168] n=3 Up [0169] or in binary [0170] n=00 Down [0171] n=01 Left [0172] n=10 Right [0173] n=11 Up

[0174] Example path:

TABLE-US-00001 Represented in symbols In plain words DOWN|LEFT|RIGHT|UP In binary 0b00011011 In hex code &h18.

[0175] Each light hub LH has four registers, one for each direction (R.sub.n (0n3)). 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.

[0176] 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.

[0177] 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 registersit is based on the Count.sub.LOCAL variable. The ID is the unique ID's of light hub's chained in the registry direction.

[0178] 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).

[0179] The registry schematically looks like:

TABLE-US-00002 pos count ID path p.sub.0 c.sub.0 ID.sub.0 h.sub.0:0, h.sub.0:1, h.sub.0.2, h.sub.0:3, h.sub.0:. . . p.sub.1 c.sub.1 ID.sub.1 h.sub.1:0, h.sub.1:1, h.sub.1.2, h.sub.1:3, h.sub.1:. . . . . . . . . . . . . . .

[0180] Each light hub LH has four counters, one for each direction (0d3). 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.

[0181] Count.sub.d (0d3) [INTEGER]

[0182] Each light hub LH also has a local counter containing the total count of all records (rows) stored in all Rd.

[0183] Count.sub.LOCAL=R.sub.d.Math.RowCount (0d3) [INTEGER]

[0184] Each light hub LH will always be in one and only one MODE, which will be explained below:

[0185] 1. Inactive

[0186] 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.

[0187] 2. Active

[0188] 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.

[0189] 3. Discovery

[0190] The System is in Discovery mode and will thus start to collect the ID's of its immediate neighbours.

[0191] 4. Master

[0192] 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.

[0193] 5. Path

[0194] 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.

[0195] 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 FIG. 10.

Embodiment(s) for the System

[0196] FIG. 1 shows multiple formwork panels P, erected adjacent to each other to build or wall-like structure, which later may be filled with concrete. As schematically depicted in FIG. 1, the formwork panels P comprise a hollow structure which is used as light channel for optical signal transmission. According to a preferred embodiment to light channels are provided in each formwork panel P, one first light channel, extending horizontally and one second light channel, extending vertically, so that the two light channels or hollow structures are perpendicular. The light channels are provided in each formwork panel P at the corresponding position, so that, if several panels are connected adjacent to each other, a non-stop light channel is generated, which extends over all the formwork panels P in one axis continuously and in a going through manner. As can be seen in FIG. 1, panel P1 is above panel P to, which in turn is left from panel P3 and so on and so forth. The floral light channel passage is depicted in FIG. 1 as dotted line, extending over the plurality of formwork panels P.

[0197] 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.

[0198] Based on the example formwork construction, given in FIG. 1, FIG. 2 shows the respective signal transmission by means of the light hubs LH. As can be seen, all light hubs LH1-LH7 are connected and may exchange signals. It has to be pointed out, that the complete signal exchange between the formwork panels P and thus between the respective light hubs' LH is exclusively optical (solid line). One of the light hub's LH is determined as being a master light hub mLH. The master light hub mLH is determined from the set of light hubs LH at which a main unit MU is attached. Only when light hub LH may be master light hub and the others take the role as slave light hubs, in the example shown in FIG. 2: all light hubs LH except LH3. The main unit MU serves as connector or gateway to a secondary electronic or computer system 2C.

[0199] 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 FIG. 2 is shown by a bidirectional arrow in solid lines, whereas the (possibly RF-based) signal transmission between the main unit MU and the secondary computer 2C may be of another type, which is shown in FIG. 2 by the arrow in dotted lines.

[0200] FIG. 3 shows a light hub LH in more detail. In the left upper corner of FIG. 3 an isometric and perspective representation of the light hub LH is shown. As can be seen in FIG. 3, the light hub LH consists of six surfaces, because the light hub has a box-like or rectangular structure. On the right side above in FIG. 3, the front side of the light hub LH is shown, which may comprise a light source set Iss (e.g., a set of photo diodes) and a light receiver set Irs (e.g., photo resistors), in particular for the communication with the main unit MU. The combination of light source set Iss and light receiver set Irs is also provided on all the other surfaces which are facing one of the light channels, in particular the left side surface, the right-side surface, the top surface and the bottom surface. These surfaces are engaging with the four light channels, two in the vertical dimension and to the horizontal dimension.

[0201] FIG. 4 shows the light hub LH in more detail. The whole unit is housed by a main body 101 preferably made of plastic or metal. A front panel 102 preferably made of plastic or metal carries one or more alignment pins 103 to steer the main unit MU into position when optionally attached to the light hub LH. The front panel 102 furthermore carries holes or translucent lenses 104 conveying light to a filter and a photocell that detects light for example using a photodiode or phototransistor 109 as well as a light emitter with a set wavelength (i.e., infrared) 110. The whole unit is held in place inside the hollow structure of the formwork panel by means of lock mechanisms 105. To enable fast maintenance refurbishment of soiled light hub's there are provided easily replaceable translucent plastic covers 106 in all four directions that protect the light transmitters and receivers behind them.

[0202] 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.

[0203] FIG. 5, schematically depicts the light hub LH with its electronic modules according to a preferred embodiment. The light hub LH consists of a microcontroller C which is used for controlling the signal transmission between the network of light hubs LH. The microcontroller C may comprise an AD/DA converter for converting light signals into digital signals and vice versa and the processing unit, which is configured to execute a predefined protocol for signal transmission. The light hub LH further consists of the light receiver set Irs (e.g., photo transistors or photo diodes) and the light source set Iss (e.g., a set of light emitting diodes/LED or laser). Further, the light hub LH may comprise a set of sensors sens, for acquiring a set of different physical parameters, comprising pressure sensors, temperature sensors, ultrasonic sensors, vibration sensors, and/or other sensor types. The sensors sens may be configured to protrude from the light hub LH into the hollow structure of the formwork panel P in order to gather the target physical parameters. For providing each of the light hubs' LH with energy, a battery may be used. Alternatively, or cumulatively, and preferably, power may be provided by means of a photovoltaic panel, attached at the outside of the formwork panel P, supplied with daylight for charging a capacitor or a super capacitor, being provided on the light hub LH as well. In case the light hub LH serves as master light hub mLH and the main unit MU is attached to the same, then power supply may be provided by means of the main unit MU. For example, the main unit MU may be configured to emit light by means of a light supply unit Is, provided on the main unit MU for charging a photovoltaic panel on the master light hub mLH (schematically shown in FIG. 6). As indicated in FIG. 5, a capacitor or a super capacitor may be provided for storing or harvesting locally harvested energy, e.g., by means of using photovoltaic cells, as described above.

[0204] As shown in FIG. 6, a photovoltaic panel may be used to charge the main unit MU. As already mentioned above, the signal transmission between the master light hub mLH and the main unit MU is exclusively light-based, whereas the signal transmission between the main unit MU and the secondary computer 2C may use other channels for signal transmission (Wi-Fi, radio frequency, WLAN etc.).

[0205] FIG. 7 schematically shows the main unit MU in several perspectives. The whole main unit MU is cased in a main body 201 preferably made of plastic. A rear side 202 of the main body is designed so that it perfectly aligns the main unit MU against one and any of a light hub front panel 102. In order to align it, one or more alignment pins 203 are used. A photocell 209 is located behind a translucent lens 204 (not drawn) and a filter mainly allows for infrared light pass. Furthermore, a light emitter 210 with a set wavelength is located behind another translucent lens (not drawn). In a preferred embodiment the unit is firmly held in place by a lock mechanism 205 exerting clamping force against the outer perimeter of the hollow structure of the formwork panel. Electric connection to external power supply or serial data communication to a secondary computer is provided by a connector 206. Furthermore, a multiband antenna 207 enables digital data two-way radio communication to any compatible secondary system or network. Energy is harvested from the sun using a panel 208 containing a multitude of photovoltaic cells and fixed to the main body by means of an adjustable hinge. When attached to the front panel of a light hub LH, the main unit MU can provide power (energy) by activating an array containing a multitude of light emitters 211 directly towards the light hub's photo voltaic panel.

[0206] On the right lower corner of FIG. 7, the main unit MU is depicted in a three-dimensional representation, here it can be seen, that the photovoltaic panel 207 is tilted.

[0207] 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.

[0208] FIG. 8 shows the data transmission between the main unit MU and the master light hub mLH. Next to the panel with photovoltaic cells on the front panel on the light hub LH, a LED, and photodiode is exposed through the glass or translucent plastic cover. This enables the light hub LH to also communicate with an optional external main unit MU placed in front of it on the outside. One or more pins ensure a perfect alignment. The main unit MU would employ an identical configuration of LED (sender) and photodiode on the surface area, attaching to the light hub LH. It would also provide power by shining light by the means of a high-power LED array on the panel with photovoltaic cells of the light hub LH. Data can then continuously be transferred between the light hub LH and the main unit MU while the connected light hub is supplied with external power. The main unit MU itself could either be supplied by the solar panel 81 a high-capacity rechargeable battery or a connection to an external power supply.

[0209] In FIG. 8, left image, the light hub LH is drawn with a distance to the main unit MU in order to highlight what takes place between them when they are docked as in the right image. Firstly, power (energy) is transferred in the direction from the main unit MU to the light hub LH. A multitude of high-power light emitting diodes are shining light directly onto the solar panel of the light hub LH. This transfers energy from the main unit MU to the light hub LH.

[0210] Secondly, data is transferred in both directions using the light emitters and photo cells (109, 110, 209, 210).

[0211] FIG. 9 shows several examples, where the formwork panels P are positioned with different angles (e.g., 70, 120, 90). In order to provide optical signal transmission through the light channels in the hollow structures of the respective formwork panels P, additional optoelectronic modules may be provided in the light channels in order to consider the angular construction of the panels P. The additional modules comprise reflectors, reflecting preconfigured wavelengths of light being transmitted. For example, a red-light reflector 91 may be used to enhance red light and to weaken other wavelengths. In a configuration phase, a specific type of reflector may be associated or assigned to the respective angle.

[0212] 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.

[0213] Further, a spacer element may be positioned between two formwork panels P, shown in FIG. 9 on the right side. A red filter 91 is fitted inside the spacer block. A light hub LH in the panel P to the right of the spacer block 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 this leads to the conclusion that a filter mainly reflecting red light is placed between the two. This information is then made available to the rest of the network comprised of all other panels. Parts of other spacer widths equipped with other filter coloration can be identified in an identical way.

Embodiment(s) for the Protocol

[0214] FIG. 10 shows a flow chart of a discovery procedure or discovery function. Light hub LH1 wakes up as tmrBeacon overflows and sends a beacon in each direction. If the beacon is acknowledged a discovery is initialized. If successful, the light hub LH1 will store the ID's of directly adjacent light hub's n in its register along with the appropriate path.

[0215] FIG. 11 shows an interaction diagram for the discovery function. Light hub LH1 wakes up as tmrBeacon overflows and sends a beacon in each direction. If the beacon is acknowledged a discovery is initialized. If successful, the light hub LH1 will store the ID's of directly adjacent light hub's n in its register along with the appropriate path.

[0216] FIG. 12 depicts the path function with a flow chart and respective processing steps. Light hub LH 1 wakes up as a main unit MU is attached to it or if another light hub issues an initPath. It sends a beacon in direction d. If the beacon is acknowledged an initPath is initialized with the following parameters:

[0217] n=the pointer to the next unread entry in the adjacent LH

[0218] The Data counter keeps track of which entry is next to be read thus n will be set to Count.sub.d+1 for this initPath try.

[0219] ID.sub.0=The ID of the Master LH that initially started the Path

[0220] 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.

[0221] 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.

[0222] Infinite loops are avoided.

[0223] The first light hub LH that initialized the transferPath provides its own ID in the request (ID.sub.0). Adjacent light hubs will respond with transferPathSkip if the requesters ID or ID.sub.0 is found on the requested Rd:n or later.

[0224] FIG. 13 shows an interaction diagram relating to a further processing of the path function.

[0225] Step 1:

[0226] 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.

[0227] 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:

[0228] Step 2:

[0229] 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 (.box-tangle-solidup.). 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.

[0230] Step 3:

[0231] 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.

[0232] Step 4:

[0233] 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.

[0234] Step 5:

[0235] 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 earliernamely the ID's and paths for all panels up until ID: 08.

[0236] Step 6:

[0237] Light hub ID: 02 now again issues the Path functionality in each direction and receives the new data that was not available earliernamely 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.

[0238] Step 7:

[0239] 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.

[0240] The registry entries look like:

TABLE-US-00003 MODE: ID: 02 MASTER R0 DOWN poscountID path R1 LEFT pos countID path 0 0 01 1 3 07 2 8 03 3 9 06 4 10 04 5 11 08 6 14 05 7 15 10 8 16 09

TABLE-US-00004 R2 RIGHT pos countID path 0 2 04 1 4 05 2 5 06 1 17 03 2 18 08 3 19 07 4 20 01 5 21 05 6 22 10 7 23 09 8 24 05 R3 UP poscountID path 0 1 03 1 6 06 2 7 07 3 12 04 4 13 08 1 3 04 2 4 08 3 6 05 4 7 10 5 8 09 6 9 05

[0241] Send function:

[0242] 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.

[0243] FIG. 14 represent schematically the send function. light hub 1 has a message to send to a light hub with ID. It looks through all register Rd to find the shortest path to ID. I then tries to initSend in the corresponding direction. The adjacent light hub will forward the message if the ID is present in one of its Rd. If an adjacent light hub refuse to initSend alternate paths are tried if possible.

[0244] FIG. 15 is an interaction diagram for the send function, which is self-explanatory.

[0245] FIG. 16 further shows details with respect to the send function. Light hub ID: 02 need to Send data to light hub ID: 09. The path to light hub ID: 09 is found in all registers d=1 to 3, that is there is a path to ID: 09 in all directions except Down. The shortest path is found in R2 with a total of five jumps (). 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.

[0246] FIG. 17 is a flow chart for a method for operating a master light hub mLH according to a preferred embodiment. After having started the method, in step SM1 panel data are provided. Panel data do comprise the unique identifier ID. In step SM 2, the provided panel data are converted to a sequence of light pulses according to the preconfigured protocol, mentioned in detail above. In step SM3, the sequence of light pulses, directed to the slave light hubs, which are integrated in directly or indirectly adjacent formwork panels PR are emitted. In step SM4, a sequence of response light pulses from the addressed slave light hubs and received response to the emitted sequence of light pulses. In step SM5, all received response light pulses are aggregated and stored locally in a registry. In step SM5, the result is generated, based on the aggregated and stored data. The result includes the aggregated received response light pulses from all addressed slave light hubs. In an optional step SM7 (represented in FIG. 17 by dotted lines), the result may be transmitted to an external unit, in particular to the main unit MU by using various data transmission channels, for example a light-based channel, or a digital channel. In any case, the result is provided on the main unit MU in a digital format. Subsequently, the result may be further processed and/or may be transmitted to a secondary computer system 2C.

[0247] 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: [0248] the identifiers of the panels P, which are present in the panel construction; [0249] the position of the respective identified panels; in particular the position information may be provided in a graphical form, as mentioned above in the detailed description, for example by using rectangles for representing the respective formwork panels P; [0250] sensor data of the specific panels, detected locally inside the formwork panel; [0251] timing information, when the panel has been erected and/or how long it is already used; [0252] comprising a measure on how much time the individual panel was stored compared to how much time it has been in use. In a preferred embodiment, this is used to automatically calculate the utilization level and perhaps to determine when it is time to refurbish the panel and/or [0253] meta information, in particular alert messages for the respective panels, e.g., indicating the requirement of replacement or a low power supply.

[0254] 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.

[0255] FIG. 18 is a flow chart for a method for operating a slave light hub according to a preferred embodiment. In Step SS 1, the beacon signal is received from an adjacent light hub LH. In response to the reception of the beacon signal, in step SS2, the slave light hub is transferred from a dormant state in an awake state. The step SS3, the receipt of the beacon signal is acknowledged. A transfer function may be applied for transferring the slave light hub from the awake state in the dormant state in step SS4. Preferably, the transfer function considers the actual power supply of the slave light hub. The lower the power supply is, the earlier the transfer in the dormant state is executed for saving power and vice versa. In step SS5 a discovery signal may be received from an adjacent light hub LH. In step SS6, the received discovery signal is propagated to an adjacent light hub LH in the same direction until a last light hub LH in said direction is reached. Further, a counter is incremented locally for each aggregated unique identifier.

[0256] 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.

[0257] 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.