Best practices for a new service that does more than collecting data

[waas1919]

Hi all

I am a bit new to EdgeX, so please me patient.
I have a question that I would like you to comment based on your experience so I know I am following the best practice since day one.

For this, let's take the following example: I have a camera that produces one image per minute.
I would like to process the image and output some analytics, like people counting.

Question 1: Does it make sense to have a Device Service that apart from collecting data (the image) does the image processing part?

I understand that this could potentially saves the core-data to store those raw images, and would store only a simple json message that could tell how many people are in range.

However, and correct me if I am wrong, this idea is a bit away from the propose of a device service, which should be just a data collector.

In case you say that what is recommended is to have the image processing on the device service itself, then I have a second question.

Question 2: What if in the future I need to collect more than one image before processing the images? In this case, I would need, let's say, 10 images before applying some analytics to the images in order to have one output like people counting..
In this case would it make sense to store the images in the core-data and then have a service that monitors how many images are stored, and for each 10 images, it would trigger a new service (a supporting service?) and after processing, it would put back the result in the core-data?

Thank you!!

[lenny-goodell]

@waas1919

Question 1: Does it make sense to have a Device Service that apart from collecting data (the image) does the image processing part?

No, that processing should be separate. Please checkout the Device ONVIF Camera and Device USB Camera services for capturing the images.
https://docs.edgexfoundry.org/3.0/microservices/device/supported/device-onvif-camera/General/
The ONVIF supports Snapshot (https://github.com/edgexfoundry/device-onvif-camera/blob/v3.0/cmd/res/profiles/camera.yaml#L224)

https://docs.edgexfoundry.org/3.0/microservices/device/supported/device-usb-camera/General/
The USB doesn't yet support Snapshot

I understand that this could potentially saves the core-data to store those raw images, and would store only a simple json message that could tell how many people are in range.

Core Data doesn't store the actual binary data for the Image snapshots, just the Event/Reading metadata. This is due to the potentially large sizes. The App Service layer will receive the Image snapshots and is the appropriate place to process them with a custom App Service: See https://docs.edgexfoundry.org/3.0/microservices/application/ApplicationServices. The custom App Service could apps the images to a CV model and the act on the inferencing results or push the results back as an Event to the EdgeX MessageBus to be consumed by other services.

Question 2: What if in the future I need to collect more than one image before processing the images? In this case, I would need, let's say, 10 images before applying some analytics to the images in order to have one output like people counting..
In this case would it make sense to store the images in the core-data

The custom app service can easily batch the images and then process them as a batch.
https://docs.edgexfoundry.org/3.0/microservices/application/BuiltIn/#batching

[waas1919]

Thanks for the reply @lenny-intel !
I though the data would enter EdgeX always via the: Device Service -> Core Data.
But from your comment, I assume that we could use the: Device Service (to get data) -> Application Service (to process data) -> Core Data (to store metadata).
Thank you!

[lenny-goodell]

The device services publish the data to the EdgeX MessageBus for any service subscribed (Core Data, App Service, Rules Engine) to receive. App Service can the publish back results from analysis for other service (Core Data, App service, Rules Engine) to consume. App Service can also sent Commands to Devices (via Core Command) based on analysis results. i.e. turn or device due to temp sensor data indicating over heating.