search

urbanobservatory / standards

Standards and schema documentation for the observatories programme
2 stars 0 forks source link

Platform vs System #12

Open EttoreHector opened 5 years ago

EttoreHector commented 5 years ago

I have some doubts about the use of "platform" vs "system".

The definitions are the following:

Platform: This can be anything from a lamppost or tripod, through to a mobile platform such as a car, van or person. Systems and Sensors are hosted on these Platforms. The Platforms are recorded in a database collection called platforms.

System: A System is a group of Sensors (possibly also actuators) that implement a Procedure. A System is hosted by (isHostedBy) a Platform. An example of System is a weather station, a group of Sensors incorporated into an integrated unit which takes readings at regular intervals.

For what I understand, Platform and System can effectively be the same thing. For example, a fixed DEFRA air-quality station is both a Platform and a System. How shall we treat these cases?

SiBell commented 5 years ago

So this is how I've been doing it (which may not be right):

As yet I haven't needed to use a system. I have sensors hosted on platforms, and these platforms can themselves be hosted on another platforms .

So using your example: a NOx probe would be a sensor (id: defra-aq-number4-nox), which is hosted on the DEFRA air-quality station (id: defra-aq-number4) which is a platform because it hosts sensors. E.g. in the SSN Docs they represent an iPhone7 as a platform. This air quality platform could then be hosted on another platform called london-road-lamppost-07.

Now let's say when the air quality gets really bad an LED display (id: led-display-serial-355253) on the lamppost starts flashing a warning message to pedestrians. This process would then be called a Procedure and thus you could then use a system to group the sensor defra-aq-number4-nox with the actuator led-display-serial-355253. By grouping these as a system it sets them apart from any other sensors/actuators on that lamppost that aren't involved in this procedure.

This is my take on it anyway.

EttoreHector commented 5 years ago

Thank you, Simon.

That clarifies things quite a lot.

On Fri, 9 Aug 2019 at 16:45, Si Bell notifications@github.com wrote:

So this is how I've been doing it (which may not be right):

As yet I haven't needed to use a system. I have sensors hosted on platforms, and these platforms can themselves be hosted on another platforms .

So using your example: a NOx probe would be a sensor (id: defra-aq-number4-nox), which is hosted on the DEFRA air-quality station (id: defra-aq-number4) which is a platform because it hosts sensors. E.g. in the SSN Docs https://www.w3.org/TR/vocab-ssn/#iphone_barometer-sosa they represent an iPhone7 as a platform. This air quality platform could then be hosted on another platform called london-road-lamppost-07.

Now let's say when the air quality gets really bad an LED display (id: led-display-serial-355253) on the lamppost starts flashing a warning message to pedestrians. This process would then be called a Procedure and thus you could then use a system to group the sensor defra-aq-number4-nox with the actuator led-display-serial-355253. By grouping these as a system it sets them apart from any other sensors/actuators on that lamppost that aren't involved in this procedure.

This is my take on it anyway.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/urbanobservatory/standards/issues/12?email_source=notifications&email_token=AB6X6YOJTWPPB4GQS2AZABDQDWGKHA5CNFSM4IKU7AZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD37BL7Q#issuecomment-519968254, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6X6YOPLOT7MSUWBSZ3P3DQDWGKHANCNFSM4IKU7AZA .

lukeshope commented 5 years ago

I agree with Simon on the definitions. A Sensor or Actuator are subclasses of System, so in our cases we will always have at least one instance of a system. A system can have subsystems for the case Simon describes, where the system as a whole has a procedure to trigger a sign, which may be dependent on multiple sensors (that are subsystems).

EttoreHector commented 5 years ago

So we will always have a sensor as part of a System, which is always eventually part of a Platform, which is always part of a Deployment.

On Wed, 14 Aug 2019 at 13:47, Luke Smith notifications@github.com wrote:

I agree with Simon on the definitions. A Sensor or Actuator are subclasses of System, so in our cases we will always have at least one instance of a system. A system can have subsystems for the case Simon describes, where the system as a whole has a procedure to trigger a sign, which may be dependent on multiple sensors (that are subsystems).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/urbanobservatory/standards/issues/12?email_source=notifications&email_token=AB6X6YLWLKZJRV33I7DM6P3QEP5E7A5CNFSM4IKU7AZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IVXUQ#issuecomment-521231314, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6X6YIMTDSJO4W3G7YV3ATQEP5E7ANCNFSM4IKU7AZA .

SiBell commented 5 years ago

I'd say a sensor doesn't HAVE to be part of a system. It's confusing because sensors/actuators are sub-classes of a system, but that doesn't mean a sensor/actuator HAS to belong to a system, they just have similar properties to a system.

lukeshope commented 5 years ago

It is confusing. I'm saying a sensor/actuator is a system (because it is a subclass), and therefore it is fine to associate sensors directly to platforms.

You can of course have more systems in between your sensors and your platforms, if you so desire.

SiBell commented 5 years ago

I'm going to throw out another example and let's see if we all agree.

Let's say a manufacturer makes an air quality protection device comprising off 3 sensors:

And 2 actuators:

So each of these 5 sensors/actuators is a system, in that sensors and actuators are a sub-class of system.

All 5 sensors are hosted by the "air quality protection device" as a whole, which is a platform.

Now the air quality sensor, the passive infrared sensor, and the servo are also part of their own system running a procedure (i.e. release a face mask when air quality is bad and person is nearby).

The battery voltage sensor and the red LED are part of a separate system whose procedure is to flash the LED when the battery is low.

Any objections to this? Happy to be proved wrong.

lukeshope commented 5 years ago

No objections, I agree with all of that.

geoanorak commented 5 years ago

I love these discussions although only lurking as not qualified to comment. But remember our principles should be about good enough for now with a little nod to foreseeable issues. Simplicity and usability above all. And I'm not saying that anything said so far strays off this path but wherever possible apply Occam's razor.  Phil

Sent from Yahoo Mail on Android

On Wed, 14 Aug 2019 at 15:34, Luke Smithnotifications@github.com wrote:
No objections, I agree with all of that.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

EttoreHector commented 5 years ago

Thank you again.

Yes, I agree with all of that.

On Wed, 14 Aug 2019, 15:23 Si Bell, notifications@github.com wrote:

I'm going to throw out another example and let's see if we all agree.

Let's say a manufacturer makes an air quality protection device comprising off 3 sensors:

  • An air quality (e.g. NO2) sensor.
  • A passive infrared sensor that detects pedestrians nearby.
  • A battery voltage sensor.

And 2 actuators:

  • A servo that releases face masks to passers by when the air quality is dangerously high.
  • A red LED that blinks when the sensors battery is low.

So each of these 5 sensors/actuators are a system, in that sensors and actuators are a sub-class of system.

All 5 sensors are hosted by the "air quality protection device" as a whole, which is a platform.

Now the air quality sensor, the passive infrared sensor, and the servo are also part of their own system running a procedure (i.e. release a face mask when air quality is bad and person is nearby).

The battery voltage sensor and the red LED are part of a separate system whose procedure is to flash the LED when the battery is low.

Any objections to this? Happy to be proved wrong.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/urbanobservatory/standards/issues/12?email_source=notifications&email_token=AB6X6YLZ6GKCSXBD2XZ7T43QEQIOHA5CNFSM4IKU7AZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4I6R2A#issuecomment-521267432, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6X6YKHNBA3H6OYAICMIDTQEQIOHANCNFSM4IKU7AZA .