LINC
Coordination middleware
Taking care of your system's consistency
Because
it's not only
about
connecting objects !
Making distributed hardware and software components
behave in a consistent and coordinated way in the elds of
Machine-to-Machine (M2M), Internet of Things (IoT),
Cloud Computing and System of Systems
Technical contact:
[email protected]
04/2016
CONNECTED CONSISTENCY
Context
“IoT”, “Cloud Computing” and “Systems of Systems” are part of our everyday life. However, the underlying complex
network called "the Internet", which is the backbone of such types of application is not the paradise described so
erroneously by the media. Despite the progress in terms of speed, bandwidth and connectivity, it remains a hostile
environment for everything connected to it.
«A distributed system is one
in which the failure of a computer you didn’t even know
existed can render your own
computer unusable.»
Leslie LAMPORT
2013 Turing Award
The Internet is an asynchronous distributed system. Errors occur without
obvious causes, with no indication of how long they will last. It is not
possible to distinguish between a faulty computer, communication link
or program; a computer that is overloaded; a link that is saturated or a
program that is just slow to respond.
Whilst browsing for a cookie recipe, if clicking on the URL has no apparent
effect, this isn’t usually a big problem because you have a human in the
loop. Re-clicking the link a few times may get you the biscuits. If not, you
change the search. It is a different story in a machine-to-machine context
because by default the machine cannot react correctly.
And yet, the same type of network that is used for cookie recipes is also used for connected health, traffic control or
building management, despite their need for safety, security and guaranteed lossless communication.
«Impossibility of Distributed
Consensus with One Faulty
Process»
M. Fisher, N. Lynch, M. Paterson
Journal ACM, 1985.
Paper recipient of (PODC) symposium Principle of Distributed Computing influential Paper Award 2001
If we have no information about what is happening, how can we keep
our application state consistent? In their 1985 paper "Impossibility of
Distributed Consensus with One Faulty Process" Michael Fisher, Nancy
Lynch and Michael Paterson explained that "it is impossible for a set of
[components] in an asynchronous distributed system to agree on a [decision],
[even if only one of them] is subject to an unannounced crash."
If we perform a set of operations, and we cannot prevent the failure of
each and every one, we cannot guarantee that they will all complete
successfully. This can lead to inconsistency or even real damage.
If a physical device is actuated, the system needs to have an accurate record of its status. Doing only half the task
leads to an inconsistency between the physical state of the system and its logical state. A door is physically open whilst
recorded as closed. A red warning light is triggered on the operators screen, while the physical warning light has
never received the order, and lives are put at risk.
«Through 2018, there will
be no dominant IoT ecosystem platform; IT leaders will still need to compose solutions from multiple
providers.»
Another issue is the plethora of heterogeneous physical devices and
software services, with different communication protocols, data exchange
formats, standards and interaction schemes. To connect and coordinate
them to offer higher level functionalities and enhanced user experiences is
no simple task. And yet, this is required for connected objects and services:
industry 4.0, smart cities, connected health, building management, to
name but a few.
Press release: Gartner.
It is no longer acceptable for a user to have to limit their choice of devices or services according to the constraints
imposed by the system. Their choice should be driven by the logic of the application.
LINC is a software solution, the result of several years of research, specially designed to overcome the limitations
of distributed systems. At last, we can use new paradigms to work at a higher level, getting rid of the drawbacks of
underlying networks, and shielded from the heterogeneity of the components.
LINC allows more reliable, efficient and lightweight applications to be built:
• More reliable, because it enforces consistency in your application;
• More efficient, because the failure management is done in the right place (at system level) and not interleaved
with your application logic;
• Lightweight because the application level no longer has to manage the complexity.
LINC also provides an abstraction layer allowing the software services, the hardware devices and even the user
interactions through graphical or tangible user interfaces to be manipulated with equal ease, using the same concepts.
As a result, you design your application as if the control were fully centralized, with no failure and with a uniform
view of all the hardware and software components you want to integrate. Thanks to LINC, your application deals
with various heterogeneous software components, and is deployed over the Internet with a decentralized control.
Leaving you free to concentrate on the application logic and not on how to recover from an inconsistent state or how
to connect and coordinate dozens of specific standards and protocol dependent components.
LINC is very versatile. It masters the inherent complexity of distributed and embedded systems. It comes with
ready-to-use components encapsulating existing standards as well as basic bricks to integrate your legacy components
(hardware and software) if necessary. LINC has also been specially designed to work with devices with very small
CPUs and low power networks, and our hard work means that you benefit from a rich user interface experience, even
on lightweight devices.
LINC differentiators
LINC radically shifts paradigm with a resource-based approach to the IoT, the Cloud and distributed systems in general,
while the current mainstream still has a service oriented approach.
«Software component technologies, including objectoriented design and serviceoriented architectures, are
built on abstractions that
match software better than
physical systems.
Many
applications will not be
achievable without substantial changes in the core abstractions.»
Edward A. Lee
Berkeley University
LINC resource-based approach
In his article, "Cyber Physical Systems: Design Challenges", Edward A.
Lee stated: "Software component technologies, including object-oriented
design and service-oriented architectures, are built on abstractions that
match software better than physical systems. Many applications will not
be achievable without substantial changes in the core abstractions.""
LINC enables us to adapt the model to the problem, and not to software
constraints when designing and implementing an application.
The IoT, Cloud and other distributed systems are usually geographically
separated physical and numerical resources. They are often critical,
possibly shared, and most of the time there is competition between
unknown, uncoordinated and uncooperative entities to access them.
Under these conditions, a resource-based approach makes more sense than a service oriented one, especially when the
services only serve as access points to the target resources.
A resource-based approach is not only more efficient, but easier to understand thanks to a direct relationship between
what is manipulated and the way it is manipulated. In LINC, the resource is the heart of the model and access to
the resource is implemented in a simple and efficient way at the model level, ensuring concurrency, synchronization,
distribution and coordination.
LINC makes implementation simple, because the management of complex systems should not result in a complex
programming environment. On the contrary, choosing the right abstraction in the right place allows reliance on high
level mechanisms without requiring the developer to implement them because they are already part of the system.
LINC makes implementation efficient because scalability is managed in the model itself, and not at application level.
The number of devices and services, size of the data and geographic distribution can all be varied with no impact on
the application.
«Future users of large data
banks must be protected
from having to know how
the data is organized in the
machine.»
Edgar F. Codd
1981 Turing Award.
Resources management
Edgar F. Codd’s seminal paper "A Relational Model of Data for Large
Shared Data Banks" begins with the words "Future users of large data
banks must be protected from having to know how the data is organized
in the machine".
The LINC resource-based approach offers this protection. In LINC, we
encapsulate the external world in “bags” (hence our name “bag-era”). A
“bag” is an abstraction layer where the resources are stored as tuples.
This choice allows these data to be manipulated through a distributed associative memory. For example, in a bag
managing the different types of sensors in a given network, the tuples would contain the sensor ID associated to
its type. From the sensor ID, you can retrieve the type and from the type you can obtain a flow of corresponding
sensor IDs. The bag paradigm is so generic that it can encapsulate most of the computer science concepts, including
databases, services, REST servers, event systems, sensors, actuators and Model-View-Controller-based graphical user
interfaces. LINC makes it possible to combine all these types of software and hardware components into an application
in a uniform way.
Regardless which of these concepts is encapsulated, a bag is accessible through a very simple and uniform API:
• read: when a partially instantiated tuple is passed as pattern the bag returns a flow of corresponding resources;
• put: when a fully instantiated tuple is passed as parameter the resource is inserted into the bag;
• get: when a fully instantiated tuple is passed as parameter if the tuple is present in the bag then it is consumed.
The operations read, get and put do not have to be put directly into an imperative language such as Java or Python but
are embedded in production rules (LINC rules) which allow the resource control to be described more synthetically.
LINC Rules
A LINC rule has two parts: precondition and performance.
Precondition permits a decision to be taken on geographically separate resources. It reads and verifies the presence
of given resources in the different bags. Contrast this with other approaches, such as the Cloud where all the data has
to be sent to a centralised location before the decision is taken. Precondition improves the response time, decreases
the number of potential failure points and does not move data unnecessarily - a vast improvement.
«Complex Event Processing can be applied to a
broad spectrum of information system challenges, including business process automation, schedule and control processes, network monitoring and performance prediction, and intrusion detection.»
David Luckham
Stanford University.
Precondition is thus ideally suited to "complex event processing" (CEP)
one of the most powerful mechanisms that can be used to implement
highly reactive systems that adapts to their environment.
As David Luckam said in his seminal paper: "The Power of Events: An
Introduction to Complex Event Processing in Distributed Enterprise Systems", "CEP can be applied to a broad spectrum of information system
challenges, including business process automation, schedule and control
processes, network monitoring and performance prediction, and intrusion
detection."
Precondition offers an inference engine which detects the conditions that
are needed to trigger an associated reaction (defined in Performance).
Performance combines the operations read, get and put to verify system status (read) and to modify it through
resource consumption (get) and resource production (put).
Performance guarantees system consistency by defining sets of operations that are applied within transactions in order
to enforce "all-or-nothing" properties. As a result, the underlying semantic is that at a given time, a set of components
have agreed on a shared vision of the system status and they have all performed the operations they were responsible
for. This is the maximum guarantee that it is possible to ensure on distributed systems. More details can be found in
the section dedicated to consistency.
In practice, precondition and performance combine powerfully: precondition infers complex events that are the
required conditions to trigger the rule; performance then offers a transactional monitor able to modify the state of the
system in a consistent way.
The LINC coordination rules embody the application logic by defining the way the resources are manipulated. We thus
have a clear separation between the system state which is the set of all the resources contained in all the distributed
bags and the application logic which is the set of rules encoding when and how the system evolves. In contrast,
classical approaches mix system state and state evolution in blocks of imperative languages. LINC offers the application
developer a much cleaner and more flexible solution.
Distribution
Everything in LINC is distributed, from the components to their control through LINC rules.
LINC is distributed because the physical system we target is distributed. Nowadays, even the very smallest boards
such as the Raspberry Pi, PandaBoard, or their industrial counterparts have several cores (computing units). To take
advantage of their power, you have to split your application and its control and distribute it over these cores. Likewise,
in the IoT, or the Cloud, the different components of an application are naturally distributed over different hosts.
The problem with classical approaches is that they do not include high level mechanisms, and therefore require a
centralised control.
LINC distributes the control. Each and every CPU of the application’s constituent components may unroll coordination
rules. The coordination schemes are aggregated to provide the full application features. Central orchestration of the
application is no longer necessary.
But what about hierarchy? Whilst an improvement on complete centralisation, hierarchy is still a limited way to
distribute the control. Imagine the leaves of a tree. You go from the leaves, through the branches to the trunk, which
acts as the centralised control. Some twigs allow you to carry out treatments such as synchronisation, fusion or
filtering. These twigs, however, are fixed in number and location. Moreover, each one can be a possible bottleneck for
information. In addition, it is the framework, and not the application logic itself, which imposes the architectural
design.
LINC, on the other hand, fully distributes the control, leaving you the choice of the location, the number and the
organisation of these treatment points. If it makes sense for the application to follow a hierarchical framework (or any
other structured organisation), it is of course possible. The control is adapted to the application and not the reverse.
Dynamicity
Run-time adaptations to your application because of context changes are not a challenge for LINC. Coordination rules
can easily be dynamically added or removed. Moreover, this rule management can even be the result of other rules,
offering you a meta-level control of the application.
LINC gives you full flexibility in deploying the control at launch time and the freedom to reconfigure it, according to
your needs, throughout the application’s life.
Replication
Not only can the control can be distributed, but it is also possible to replicate part of it. In this case, the machines
responsible for the same control work together in order to ensure that the application is never interrupted, even if one
of them fails. LINC’s high level mechanisms guarantee such replicated control is seamless and invisible, appearing as
if it were operated by a single controller.
Obviously this feature can be used to keep an application functioning, even in case of hardware failure, but it also
allows a machine to be shut-down, for example for maintenance, without stopping the application. Start a spare
machine and put on it the same control rules as the machine to stop. Shut-down the latter and the spare machine
automatically takes the relay without interrupting the application. Complete the maintenance, restart the machine
with its original control rules and stop the spare machine to be back to the initial configuration. Easy!
Consistency
As mentioned in the introduction, we’ve known since 1985 that in an asynchronous distributed system, if a message is
not received, it is not possible to distinguish between a computer that is slow or that has faulty software, hardware or
just a bad connection. We do not even know if or when the message will eventually be received. We can therefore
consider the environment in which we deploy our applications as “hostile” to our communications. Trying to ignore
this, claiming that it is not important, or not likely to happen is just brushing the truth under the carpet.
«Transactions are an all or
nothing thing, either they
happen completely or all
trace of them (except in the
log) is erased.»
Even LINC cannot prevent failure from occurring, but it can offer clear
information that allows a sensible decision to be taken such that the
consistency of the system is not compromised. Two mechanisms allow
this: distributed transactions and distributed consensus. In LINC we have
chosen the first.
Distributed transactions offer a particularly interesting property: Atomicity, also known as "all-or-nothing". This guarantees that if we perform
a group of actions embedded in a transaction then either all of them
are performed or none of them. In other words, a group of operations
has no impact on the system if we are not able to complete all of them
successfully.
This simplifies the application designer’s life considerably since the system is always in a coherent state. Either it
evolves between coherent states or it remains in the original one.
"Operating Systems: An Advanced
Course", Springer Berlin Heidelberg,pp 393 – 481, 1978
Jim Gray
1998 Turing Award.
As an example of how much effort this saves: Imagine the system is in a state A, and five actions (for instance,
modifying information in different databases, calling booking services, notifying the customer, etc.) need to be
performed to reach state B. Some of these actions can fail or just be suspected to be faulty. Without distributed
transactions, a quick computation shows that we have 25 = 32 possible resulting states. Only two states preserve
consistency: either no action is performed (stay in A) or all actions are performed successfully (reach B). The others
make the system more or less inconsistent and would require intervention. Using a distributed transaction ensures
that we would only consider the first two. The number of possible inconsistent states grows exponentially.
We can take the analogy of a person who wants to cross a river. The desired state is “being on the other side”. The
default state is “being on the initial side”. If before crossing, they carefully plan the full set of actions to be taken, they
will either get to the other side safely, or decide to stay where they are to find a better way. If they plunge into the
river with no planning, they could get stranded midstream, and spend a tremendous amount of energy trying to swim
safely to one of the two banks.
We can save the application designers a great deal of metaphorical swimming if they only have to consider being
safely on one of the two banks. They only code for the two states that correspond to the application logic, and no
longer waste time catching system failures from the incoherent states that correspond to an incomplete execution of
what was planned. This not only drastically reduces the size and the complexity of the code, but more importantly,
ensures correct application behaviour at all times.
Cost of distributed transaction
But I’ve heard that the distributed transaction mechanism can be costly? It’s true that because it implies a severalphase-protocol, it may be seen as costly. Moreover, one could argue that it is always possible to implement a transaction
when required at the application level. So how do we justify our choice in LINC?
Firstly, transactions are costly if implemented afterwards, in the same way that putting air conditioning in a car costs
almost nothing if you do it when you build the car, but it is very expensive if you have to add it later. Moreover,
implementing transactions at the application level requires particular technical knowledge from the programmer
which is exactly the opposite of LINC’s philosophy. LINC is a programming environment for programmers who master
the application domain, not distributed system programming experts.
Secondly, the rules of distributed transactions can be relaxed once implemented in LINC because we are mainly
interested in the Atomicity properties. Their implementation at the heart of LINC has been tuned to reduce both
execution time and memory usage. In addition, if for some actions, a transactional guarantee is not relevant, the
system is optimized to escape the unnecessary phases of the protocol. This optimization allows us to implement a
general purpose transactional monitor on a Raspberry Pi while other systems providing transaction capabilities would
have to run it on a multi-core server.
LINC provides the best of both worlds: a very efficient way of managing distributed transactions, only when required.
Reflexivity
LINC is a reflexive environment. This allows us to implement all the features using either one of, or a combination of
the three concepts that we described above: associative memory, production rules and the distributed transactions.
LINC follows the “onion” principle. At its heart, a highly optimized kernel which implements these three basic concepts.
Surrounding it, layers which define additional features, again only based on these three concepts. LINC is therefore:
• compact: it is no longer necessary to deal with several completely different environments and programming
styles. Other frameworks may have one for encapsulating the devices and services, one for capturing the
application logic, one for the graphical interface, etc.;
• robust: because the same concept is used in different situations we have a better test coverage;
• efficient: because only three concepts have to be implemented, not only is time saved, but optimisations are
applied across the whole application;
• evolvable: new features can be implemented very quickly as a combination of the three concepts.
For instance, maintaining coherence in a set of rules is usually very difficult and error prone and this may be why
rule based systems have such a bad reputation. In LINC, reflexivity helps to solve this problem. Each rule has a
corresponding resource which denotes whether the rule is active or not. If the resource is available, it is active, if not,
it is deactivated. The rule verifies that the resource is present in the precondition phase and in each of the transactions
of the performance phase. If this resource is removed, then:
• in the precondition phase, a garbage collect is triggered in the inference engine to remove all traces of the rule;
• in the performance phase, all the transactions are aborted because it is not possible to access the resource.
Thus, as soon as the resource is removed, the rule has no further impact on the system. Even if the rules are distributed,
we still have a coherent idea of what is happening in our application. This is implemented at no cost, it does not
require heavy testing and each time we improve the implementation of the transactional engine or the bag’s primitives,
this mechanism is improved.
User interfaces
LINC does not differentiate between the user interface and the rest of the application. A user interface, graphical or
not, is seen in the same way as a set of sensors and actuators. Indeed, there is no semantic difference between a value
issued from a sensor, and clicking on a graphical or physical button, shaking a phone or a remote controller, moving a
green square over a red circle with a mouse, etc.. In the same way, opening a door, lighting a red signal, playing a
sound, triggering the vibration on a phone or changing the size, the colour or the angle of a square on a screen are
just actuated feedbacks. It becomes much simpler to build the application, mixing graphical and tangible interfaces to
offer a far better user experience.
The Model-View-Controller (MVC) approach is a recognized best practice in terms of graphical user interfaces. Teamed
with LINC’s resource-based approach, the synchronisation of interfaces running on different devices becomes natural
and easy. It is even possible to control what is local to your device and what needs to be synchronized, for collaborative
work, for instance.
The rendering is fully scalable for all screen sizes with no loss in quality, through the use of Scalable Vectorial Graphic
(SVG) technology. For highly dynamic interfaces, including real-time updates of simulators and charts, we have
adopted the SNAP SVG environment provided by Adobe to replace Flash. Its main advantage is that no proprietary
plugging is required since it is based only on SVG and Javascript. Even devices with small CPUs can have dynamic
screens thanks to our extremely lightweight Ajax/Javascript library. All this can run on a smart phone out of the box
without any prerequisite installation.
Our emphasis is on making the implementation and use of the user interfaces as easy and rapid as possible. For this
reason, all these technologies are web based. Indeed, HTML5, SVG and Ajax/Javascript provide a very powerful
environment, allowing smooth user interactions to be defined. Correctly used, you can design interfaces that fit any
devices running a web browser: computer, laptop, notebook, tablet, smart-phone, PDA, TV, and even small e-book
readers such as the Amazon Kindle.
Scope
LINC can be applied anywhere that data has to be distributed, and software components and physical devices
coordinated. LINC is not constrained by hardware, and can go from embedded systems to widely distributed
applications with the same abstraction.
We have to be honest though. Although LINC is extremely flexible, there are some domains where it is not the best
choice (or at least not as the main actor).
For instance, when the data to be manipulated are not discrete: e.g. a video stream. We can control the source,
the sink and the connection between them, but the stream should be managed by something else. In this case, we
would combine LINC with a middleware dedicated to video stream management. We offer the control, they offer the
diffusion.
Likewise, LINC is not suitable for highly data intensive applications, such as 1000 sensors placed on the wing of
a plane with 1000 measurements per second. For such high rate systems, you should probably install dedicated
middleware and hardware. Having said that, if you want to have 10 sensors, with 100 measurements per second on
the wings of 1000 planes, flying all over the world, LINC is a great choice!
Neither is LINC suitable for hard real-time applications, such as autonomous unmanned vehicle control. We can follow
the vehicles, and coordinate their progress as a fleet, but the high speed data fusion for obstacle avoidance requires
specialised software, and LINC is just not designed for this type of application. It is asynchronous by nature, with
synchronization on demand when required by the application. By not synchronising operations by default, arbitrary
dependencies between independent operations are removed, and response time is optimised through a better use of
hidden parallelism. In summary, we do not enforce real-time control and this is why we can offer a better response
time on systems running on general purpose networks. Of course, real-time, and response time as perceived by
the user are two different things. Most of the time, people ask for real-time, meaning that they just want to have
something responsive, and LINC is then the ideal choice.
LINC implementation examples
LINC is a tool box dedicated to easing the development of applications which integrate hardware and software
components. It has been implemented in several domains, and we give five examples here that illustrate some of
those domains and how we took advantages of LINC’s properties.
Large scale distribution
Our demonstrator monitors and controls a group of
buildings spread over different locations (1 in Ireland
and 3 in France). We integrated proprietary software
components, and coordinated them through LINC on
the different partner sites (Ireland, France, Germany
and Netherlands).
For this European project we integrated a large number of different sensor network technologies, both
wired and wireless: LON, KNX, 6LOWPAN (Telosb,
Watteco), 433Mhz (Chacon, Oregon, OWL, Blyss),
802.15.4 (Xbee, Plugwise). We also used LINC to
coordinate autonomous proprietary subsystems not
initially designed to work together.
Specifically, we used alarm system information to infer
the presence of people inside the buildings and control
the heating, ventilation, and air conditioning (HVAC)
systems accordingly to reduce the energy consumption.
Using LINC, we succeeded in cutting energy costs by
as much as 40%.
Complex Embedded System
We co-developed this prototype with a startup who
wanted to fit a laboratory into a flight case.
This tiny laboratory automatically analyses samples
to detect disease markers. The user interface is wireless, meaning that you can connect to the box with
any web browser (e.g. from a PC, tablet or smartphone). The configuration and the workflow are fully
configurable to the users’ needs. It integrates and coordinates, through a dedicated workflow language,
physical sensors and actuators of different types:
•
•
•
•
•
•
•
fluidic,
pneumatic,
electronic valves,
step motors,
peltier unit,
ultra violet light
high definition camera.
We co-developed this remarkable laboratory with an
engineering consultant (who was responsible for the
physical build), and the startup’s expert (who defined
the biologic process). Through LINC, we provided the
software integration and the remote graphical user
interface.
High rate sensor processing
Another co-development for a startup, this prototype
smart table aids in urban mediation, allowing urban
infrastructure designers, project deciders and the affected inhabitants to discuss the proposed developments. They use the smart table both as a physical
model of the urban sector under consideration and as
an interaction medium to augment the model with a
3D virtual representation of the same urban scene.
Physical models of each building can be put on the
table. These buildings are made with a 3D printer and
they are equipped with radio-frequency identification
(RFID) tags to allow interaction with the table. An
additional external screen or a projector is used to
render the urban area as a virtual 3D scene. This
allows the user to fly over the full scene or to move
around within it.
The smart table embeds and controls:
• a matrix of 384 RFID readers;
• an HD display acting as a dynamic tablecloth;
• different tangible objects, such as building models;
• a 3D mouse;
• a 2D renderer for the tablecloth;
• a 3D renderer for the 3D scene.
An engineering consultant was responsible for physical
table integration. The software integration and the
user interactions were accomplished with LINC.
Rapid prototyping
The French government research program IRT Nanoelec aims to bring together industrial and academic
partners. One of their projects is a smart car park
integrating:
• industrial prototypes such as the charging stations and the vehicle detectors;
• off-the-shelf equipment such as light signals,
gates, cameras, etc.;
• software components such as a database and a
proprietary environment.
Three applications were developed on top of the same
hardware and software components. The first application for the car drivers uses mainly SMS interactions
through a smartphone. The second application is for
the maintenance team. It offers a full supervision of
the car park through a web interface and allows the
different equipment, lights, cameras, etc. to be activated. It also alerts the team to any equipment failures.
The third application is for the car park manager and
through analytics it allows the latter to optimise the
usage of the parking spaces according the context (e.g.
pricing vs. number of spaces free).
This demonstrator was developed in three months
for the Sustainable Mobility Day on 18/11/2014, in
parallel with the prototype of the charging station.
The deadline was fixed, but various elements were
delayed, and only the ability of LINC to easily simulate
missing modules allowed the project to be completed
on time. The final version of the last charging station
was delivered 3 days before the deadline.
This open environment has since been upgraded with
smart lighting and is used as permanent demonstrator.
Multi-channel gateway
This pre-series co-development was carried out with a startup which provides sensor networks to monitor the deformation of structures.
Sigfox
Cloud
Sensor network
Alerts
The aim was to develop a gateway for their networks with
different communication channels adapted to the context.
It includes:
• a Wi-Fi connection to configure the network anytime,
for example, at deployment or during maintenance.
• a 3G connection to push the data to external servers
(cloud or private storage).
• a SIGFOX connection to raise an alert, for instance
when 3G connectivity is lost.
Their networks contain up to 255 sensors, with a maximum
sampling rate of 1 Khz. To meet these demands, on-the-fly
compression is done in the gateway before the push to the
storage server.
This architecture is of course easily adaptable to other types
of networks.
Sigfox
3G
GATEWAY
Data
WIFI
Con guration
Our mission
We help you to boost your time-to-market by accelerating your product development. You get the benefit of our tools
and wide-ranging expertise in the field of connected objects and services. We complement your skill-set, working
closely with your team or with a hardware integrator.
LINC becomes part of the different frameworks you use in your daily work. It decreases development time and
complexity, and increases the maintainability of your final product.
We provide you with LINC, then help you to master it with targeted training and support. We also help you to
implement best practice, and aid you in the development of some or all of your projects.
[email protected]