3. FIWARE is Standard for Context Data Management
2
All context broker
interactions use NGSI v2
NGSI v2 is a vendor neutral
interface
Standardized interfaces
promote competition
IoT Networks don’t directly
write to the Context Broker
in the standard
Architecture
4. What is the issue?
3
Heterogeneous environment of devices
Different protocols (due to
the lack of globally accepted
standards)
Different Transports
Custom Message Formats
5. What about “unified” IoT Platforms?
4
IoT Platforms have their uses but one size does not fit all. It is
impossible reconcile all of the following:
554
Low power
consumption
Low
latency
High
accuracy
Low
Cost
6. Solution: IoT Agents
5
Simple configurable NSGI to platform-specific middleware for each
incoming message format, answers common problems
How to decide which supported transport to use?
How to map attributes?
How to serialize commands?
How to deserialize measures?
How to include additional static data?
7. Solution: IoT Agents
6
A growing number of free open-source IoT Agents are already
available:
IoT Agent for JSON – HTTP/MQTT messaging (with a JSON payload) and NGSI
▪ IoT Agent for LWM2M – Lightweight M2M protocol and NGSI
▪ IoT Agent for Ultralight – HTTP/MQTT messaging (with an UltraLight 2.0 payload)
▪ IoT Agent for LoRaWAN – LoRaWAN protocol and NGSI
▪ IoT Agent for OPC-UA – OPC Unified Architecture protocol and NGSI
▪ IoT Agent for Sigfox – a bridge between the Sigfox protocol and NGSI
8. Demo: Build your own IoT Agent
7
Don’t start from scratch - take an existing IoT
Agent as a template and modify.
package.json - include iot-agent-node-lib
Remove unnecessary bindings and config -
checkMandatoryParams()
Payload lands in the parser -
• parse() - northbound measure
• command() - southbound command
• result() - northbound command
Use libraries to manipulate payload
9. Takeaways: Build your own IoT Agent
8
You don’t have to start from scratch
• take an existing IoT Agent as a template and modify
Debugging and HTTP Error codes are your friend
Use a test-bed to test in Isolation
• IoT Agent
• Orion
• Database (Mongo-DB)
Test with direct communication with the South Port
• use Postman for HTTP
• post MQTT topics to a broker
• send bytes down the wire
Comply with licensing - AGPL 3.0
10. Tales from the trenches:
9
Your agent is defined by the protocol specifications.
Read and understand the specs
• Most specs can be “open to interpretation”.
• Don’t necessarily need to apply the full spec
all at once.
• Decide which variants are worth supporting
commercially
How to map attributes?
• This depends on the protocol:
□ For LWM2M a strict format is predefined
□ For LoRaWAN not full specified - Cayenne Lpp, CBOR
• Use the config and provisioning data to guide your mapping.
When starting very useful to have a testbed
• Orion + IoT Agent + South Port
11. Tales from the trenches:
10
Hardest part - ensuring test coverage
A partial implementation can still be commercially useful.
• For some protocols adding commands maybe unnecessary.
• For LoRaWAN only class C could receive downlink messages
AGPL was not seen as an impediment
• Considered as a reasonable license for an open-source community project
12. Summary
11
"In every operation there is an above the line and a
below the line. Above the line is what you do by the
book. Below the line is how you do the job."
— John le Carré (A Perfect Spy)