Please find the description of the proposed solutions Stay Put and Simple State here:
For further information about how these generic IoT-solutions feed in to a “bigger picture” vision/strategy, see this presentation:
And the Working Table agenda for Simple State here:
Find the Working Table agenda for Stay Put here:
Greetings from Aarhus
Jeppe, Mikkel and Kim
I’m curious how this relates to the tracking of ‘Road beacons’ in GeoNetBake:
Hi Boris,
I think there are similarities, but Stay Put solutions are meant to be quite simple, as (I believe) opposed to GeoNetBake solutions which are quite sophisticated, if I remember correctly.
Basically, we just retrofit an off-the-shelf sensor to a piece of equipment, connect it up to a standard, off-the-shelf platform, show stuff on a map, and create some alerts for people who need them. For the time being, this is for (somewhat) rapid prototyping and smaller projects. If the projects grow, we might reevaluate what to do with them.
What we hope to do re SCORE is to share and specify what we do, with what equipment, and how we do it, sharing descriptions, flow, code snippets and does-and-dont’s, so other cities can use this for simple, fast IoT prototyping.
Cheers,
Mikkel
Hi Boris, hi Mikkel,
I see some similarities in the Monitoring of the sensors. That is also what we want to do with GeoNetBake in SCORE. To monitor the positions of the beacons.
And in the Monitoring the simplicity of the data shouldn’t make a big difference. Maybe we can have a Chat on that tomorrow in the working tables.
Best regards
Henning
Working table 1 notes: "Simple State"
…
Q: Are these solutions intended for prototyping or for production/upscaling?
Both. The flexibility of the concept and platforms should allow both for rapid prototyping of few devices for a use case and for scaling to larger “production like” platforms.
Q: What is the concept of “archetypes”?
It’s the idea of creating a set of simple, generic IoT-based solutions that can be used in a multitude of use cases. Everything surrounding the sensor itself (testing, assuring good quality, checking battery life
Q: Can these solutions be specific instead of generic?
Yes, the third case we’re looking at (not in scope for SCORE) is very specific to the context/domain. The platform/infrastructure being used should be able to
Q: What LPWAN is used for these IoT solutions?
LoRaWAN for now but should be decided on a case-by-case based on what transmission technology would work best for the best case
Q: Is the LPWAN running in private or shared mode?
Started out as shared/roaming but might need to move to private because of legal issues
Q: Is the LPWAN built on own assets/buildings and on own backhaul infrastructure?
Yes, on city-owned libraries/schools and on municipal fiber
Q: Can the strategy be shared?
Yes, it’s not in any way done yet but can be shared (also for input) along the way. More relevant maybe - also our proces/learnings along the way that lead to the strategy can be shared
Q: can you elaborate more on your use cases and business value so far or can you share info on that
Business value for electrical cabinets could be the ability to monitor the temperature, to avoid equipment damage and fires, and monitor humidity, to get early warning of leakage or flooding. For road temperatures (specifically bike lanes), business value could be timely data on need for gritting or snow removal during winter, to keep bike lanes open so hopefully fewer citizens will resort to commuting by car. For room temperature, we think of a specific instance of some elderly people becoming agitated if the room they are in is too hot, so measuring temperature will enable staff to move them to a cooler room if needed.
Q: Don’t these requirements for the archetypes differ between contexts?
Yes, and maybe one archetype actually consist of several “pre-approved” options that allows for different sizes, mounting options etc.
And the strategy part hovering “above” these archetypes define in a standardised way how to “put new solutions on the shelf” and the process for “putting archetypes into use”, e.g. how to best mount a device, placement considerations for this or that specific archetype sensor etc
Q: How can we make the solution(s) more shareable and applicable in other business areas?
Create five practical toolkits that help people set up simple versions of what they want to obtain in the long time.
What are some additional use cases/archetypes you come to think of?
Yunus: Movement sensor in homes (elderly), living room + bedroom. Based on specific needs from “Adults and Elderly” department. Sigfox worked perfectly fine indoor
Tim: Sheep that come into the city and eat grass (instead of mowing)
Most important requirements for sensors
Make sure you use stable suppliers that are well-known and can deliver/replace if issues.
Make sure battery life is good and the robustness of the solution and visually discrete in the urban space
Privacy and perceived risk of the “thing” in the street
Awareness of biases in documentation
Additional notes:
What are your ideas for other use cases in the Simple State project
What are the most important requirements for sensors?
What are the most important requirements for data visualisation and alarms (e.g. email alarms)?
What are the most important requirements in general?
How can we make the solution(s) more shareable and applicable in other business areas?
What are your ideas for other archetypes than Simple State?
Working table 2 notes: "Stay Put"
…
Q: Lifesaver: how many sends a week/a day. Does it ping more when it is not at its normal location?
Normally sleeps, accelerometer wakes it up and starts sending GPS coordinates when the life saver is moved.
Any ideas for other use cases?
Vinny: Defibrilators
Adrian: Its not necessarily about staying put but in the UK individuals will use the electricity intended for the street light for their own use e.g. steal the electricity. So if you are adding some sensor technology it could be worth some form of monitoring of the power usage?
@Syd, Yes flap valves would be useful, however many are owned by Scottish Water a separate authority. I would need to think a bit further to find other possibilities.
Kim Lantto: Our air quality project sensors are not that robust but easy to build: https://luftdata.se/bygg/
Q: So I understood that you use an open source management system for the monitoring of the sensors, right?
Yes, but currently no. We currently use the commercial version of ThingsBoard but want to go (and extend) the OS/community version.
Q: How do you monitor data, do you have any automatic event detection (event = it has been moved)?
Yes, event monitoring will be part of the solution
Q: Is total cost of setup of new idea a barrier. For eg. equipping one single tree for a test period vs. equipping all risk trees at once to have a lower “per tree” price.
Aim is to lower the price by making the solutions generic, easier/cheaper to buy and implement in bulk and the platform shared across all different use cases.
Q: A related question about this: Here we have had this conversation about whether the city department or ‘we, the tech builders & bringers’ are the ‘product owner’ of what is built. How do you look at the product owner role in Aarhus?
On-going discussion. Shifts over time - we push ideas, prototypes etc. until the business is mature enough or ready to pull these and additional solutions.
Q: So who provides ongoing support? Developer or owner?
Depends on the setup (commercial vendor offering support, internal super users etc.)
Dhaval: Apache Flink offers a Complete Event Processing framework - and we have some experience of dealing with it. If you can share data, we can definately look into it (I have a PhD student)
Tim (re: business cases/value)
Thanks, should you document these business value extrapolations from the prototype. Please do share with Justine for SCORE business case template.
Most important requirements for sensors, visualisation and alarms
Long battery life
Should blend in with environment
Reliability, low maintenance
Data accuracy
Robustness
Share experience from implementing devices
Easy to install, idiot proof as operatives might not have technical skills
Battery replacement or charging requirements
Reduce false alarms
Geofencing
Battery levels and also devices not sending data, but also alerts around LoRaWAN gateways being down
Resilience on your gateways, networks etc.
Also need to consider test and production gateways
Most important requirements in general
A business case
Maintenance
Separate get it up and running (which not everyone is interested in), and keep it running
Manage expectation of stakeholders vs reality
Transparency to achieve acceptance by the public
Trust in the longevity - the solutions, platforms etc. will live on
Other ideas for archetypes?
Kits especially opening up certain local possibilities for citizens. The city provide the hardware and allow citizens to create measurements.
Humidity in flower beds
As a city you also face certain challenges regarding security of certain events, like G20 where you need to close certain infrastructures like shafts, using sensors would be way cheaper then for example closing them using manual labor
monitoring dangerous structures/subsidence
Additional notes:
What are your ideas for use cases in the Stay Put project?
What are the most important requirements for sensors?
What are the most important requirements for data visualisation and alarms (e.g. email alarms)?
What are the most important requirements in general?
How can we make the solution(s) more shareable and applicable in other business areas?
What are your ideas for other archetypes than Stay Put?