Topics

Communication ways between EXF devices

Jihun Ha
 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

Drasko DRASKOVIC
 

Hi Jihun,

On Mon, Aug 7, 2017 at 7:35 AM, 하지훈 <jihun.ha@...> wrote:

Greetings,



I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)



BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.



For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.



At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?



I'd appreciate if anyone can give a clue for my question :)
Welcome to EdgeX project!

Janko (in CC) is leading Application WG, and Distribution Service
falls in his domain. He can shred some light.

BR,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

James.White2@...
 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To: edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

Jihun Ha
 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To: edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

Drasko DRASKOVIC
 

Hello Jihun,

On Tue, Aug 8, 2017 at 2:35 AM, 하지훈 <jihun.ha@...> wrote:

Hello. Jim White.



Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?
You can always map the Docker containers ports to the host ports using
`-p` option. Please refer to the `docker run` reference, chapter
"Exposing Ports": https://docs.docker.com/engine/reference/run/

"To expose a container’s internal port, an operator can start the
container with the -P or -p flag. The exposed port is accessible on
the host and the ports are available to any client that can reach the
host."

Best regards,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Tiejun Chen
 

In my understanding, the rules engine is really an export service client since it always registers itself as an Export Client by means of the Export Client Registration microservice automatically. So it can receive all events and readings through the Export Distribution microservice. Across different EdgeX nodes they communicate ZeroMQ and plus gateway ActiveMQ, instead of container.

Thanks

Tiejun

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Tuesday, August 8, 2017 8:35 AM
To: edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential


Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To:
edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

James.White2@...
 

Hi again Jihun,

As Drasko pointed out in his response, we actually expose all the ports with the –p option.  Still, there are complexities and issues with this whereby we do believe a better container orchestration and configuration system would be more appropriate long term (Swarm as one possibility).  Each micro service has been written independent of the others (and even container technology) so there is no reason why the micro services couldn’t be much more broadly distributed or managed by some different strategy.  We just need to figure out what is the best mechanism to do that – and hopefully not try to re-invent the wheel when doing it.

This may also be an area where 3rd parties (some commercial ) provide value add.

Jim

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 7:35 PM
To: edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential


Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To: edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

James.White2@...
 

Hi Tiejun,

You are correct – by default, the rules engine is a registered client of the export distribution service and receives all data coming up through core data via the export distribution service.  However, there are configuration options in EdgeX that allows core data to send data directly to the rules engine (and bypass the export distribution service).  This has pluses/minuses associated with it.

The export distribution service has the ability (the responsibility) to filter, transform, format, etc. the data for any application (like analytics engines or rules engines) or the cloud, enterprise system, or next level of the fog hierarchy.  So bypassing this layer, means the rules engine (or any service) is getting the raw data from core data and must take on these responsibilities on its own.

The reason for the direct feed option is to enable a quicker feed of the data to edge intelligence systems (rules engine, analytics, etc.) for those more near-real time needs (for example, you may want the motor actuation to happen quicker when the engine is determined to have some anomaly that requires immediate shutdown).  Indeed, if there is no need to pass the data further than the local edge node, the export services may actually be removed.

Across EdgeX nodes, we don’t yet have a formal orchestration means to get data across nodes, but the export services (with client registration and distribution service) can be used to have an analytics capability (or a rules engine micro service) on another EdgeX platform to register for the data from another instance of EdgeX.

Jim

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of Chen, Tiejun (VMware)
Sent: Tuesday, August 08, 2017 2:55 AM
To: jihun.ha@...; edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

In my understanding, the rules engine is really an export service client since it always registers itself as an Export Client by means of the Export Client Registration microservice automatically. So it can receive all events and readings through the Export Distribution microservice. Across different EdgeX nodes they communicate ZeroMQ and plus gateway ActiveMQ, instead of container.

Thanks

Tiejun

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Tuesday, August 8, 2017 8:35 AM
To: edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To:
edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

Tiejun Chen
 

Jim,

Thank you for your elaboration on it. Yes, from https://wiki.edgexfoundry.org , I noticed there is another sort of quick path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since we’re trying to deploy EdgeX on VM residing on IoT gateway. You know, under hypervisor we can install multiple VMs on one IoT Gateway so that means we can deploy several EdgeX nodes on one IoT Gateway. So I think we keep Core Services Layer, Supporting Services Layer and Device Services Layer within one VM but probably bring Export Service Layer into another VM, because just Export Service Layer mostly interacts with external like off-gaterway client, or distributed on-gateway client for other telnet. It’s getting a risk of being attached. So if we can isolate it, we can protect other basic layers to make sure EdgeX can continue working in some ways.

Overall, it looks like the big picture including some following items in my mind.

  • Isolate and separate Export Service Layer
  • Trim down EdgeX to make sure it can be customized only to have necessary components to one given telnet
  • Construct light weight VM to carry out EdgeX
  • Provide secure inter-VM channel between Export Services Layer and other layers
  • Others

Any comments will be appreciated.

Thanks

Tiejun

From: James_White2@... [mailto:James_White2@...]
Sent: Tuesday, August 8, 2017 10:36 PM
To: Tiejun Chen <tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Hi Tiejun,

You are correct – by default, the rules engine is a registered client of the export distribution service and receives all data coming up through core data via the export distribution service.  However, there are configuration options in EdgeX that allows core data to send data directly to the rules engine (and bypass the export distribution service).  This has pluses/minuses associated with it.

The export distribution service has the ability (the responsibility) to filter, transform, format, etc. the data for any application (like analytics engines or rules engines) or the cloud, enterprise system, or next level of the fog hierarchy.  So bypassing this layer, means the rules engine (or any service) is getting the raw data from core data and must take on these responsibilities on its own.

The reason for the direct feed option is to enable a quicker feed of the data to edge intelligence systems (rules engine, analytics, etc.) for those more near-real time needs (for example, you may want the motor actuation to happen quicker when the engine is determined to have some anomaly that requires immediate shutdown).  Indeed, if there is no need to pass the data further than the local edge node, the export services may actually be removed.

Across EdgeX nodes, we don’t yet have a formal orchestration means to get data across nodes, but the export services (with client registration and distribution service) can be used to have an analytics capability (or a rules engine micro service) on another EdgeX platform to register for the data from another instance of EdgeX.

Jim

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of Chen, Tiejun (VMware)
Sent: Tuesday, August 08, 2017 2:55 AM
To: jihun.ha@...; edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

In my understanding, the rules engine is really an export service client since it always registers itself as an Export Client by means of the Export Client Registration microservice automatically. So it can receive all events and readings through the Export Distribution microservice. Across different EdgeX nodes they communicate ZeroMQ and plus gateway ActiveMQ, instead of container.

Thanks

Tiejun

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Tuesday, August 8, 2017 8:35 AM
To: edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To:
edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

James.White2@...
 

Dell - Internal Use - Confidential

Tiejun,

Sounds like some neat work.  The microservices approach allows for these kinds of considerations and distribution – perfect!  At this point, you are out in front of some of us in thinking about certain distribution and deployment concerns, but that is great and your work can help identify issues we need to address.  You may also want to tie in with the EdgeX security working group as some of the isolation / separation concerns are things they want to address and they might have ideas that could address some of your concerns (and vice versa).

Jim

From: Chen, Tiejun (VMware)
Sent: Wednesday, August 09, 2017 2:32 AM
To: White2, James <James_White2@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Jim,

Thank you for your elaboration on it. Yes, from https://wiki.edgexfoundry.org , I noticed there is another sort of quick path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since we’re trying to deploy EdgeX on VM residing on IoT gateway. You know, under hypervisor we can install multiple VMs on one IoT Gateway so that means we can deploy several EdgeX nodes on one IoT Gateway. So I think we keep Core Services Layer, Supporting Services Layer and Device Services Layer within one VM but probably bring Export Service Layer into another VM, because just Export Service Layer mostly interacts with external like off-gaterway client, or distributed on-gateway client for other telnet. It’s getting a risk of being attached. So if we can isolate it, we can protect other basic layers to make sure EdgeX can continue working in some ways.

Overall, it looks like the big picture including some following items in my mind.

  • Isolate and separate Export Service Layer
  • Trim down EdgeX to make sure it can be customized only to have necessary components to one given telnet
  • Construct light weight VM to carry out EdgeX
  • Provide secure inter-VM channel between Export Services Layer and other layers
  • Others

Any comments will be appreciated.

Thanks

Tiejun

From: James_White2@... [mailto:James_White2@...]
Sent: Tuesday, August 8, 2017 10:36 PM
To: Tiejun Chen <tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Hi Tiejun,

You are correct – by default, the rules engine is a registered client of the export distribution service and receives all data coming up through core data via the export distribution service.  However, there are configuration options in EdgeX that allows core data to send data directly to the rules engine (and bypass the export distribution service).  This has pluses/minuses associated with it.

The export distribution service has the ability (the responsibility) to filter, transform, format, etc. the data for any application (like analytics engines or rules engines) or the cloud, enterprise system, or next level of the fog hierarchy.  So bypassing this layer, means the rules engine (or any service) is getting the raw data from core data and must take on these responsibilities on its own.

The reason for the direct feed option is to enable a quicker feed of the data to edge intelligence systems (rules engine, analytics, etc.) for those more near-real time needs (for example, you may want the motor actuation to happen quicker when the engine is determined to have some anomaly that requires immediate shutdown).  Indeed, if there is no need to pass the data further than the local edge node, the export services may actually be removed.

Across EdgeX nodes, we don’t yet have a formal orchestration means to get data across nodes, but the export services (with client registration and distribution service) can be used to have an analytics capability (or a rules engine micro service) on another EdgeX platform to register for the data from another instance of EdgeX.

Jim

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of Chen, Tiejun (VMware)
Sent: Tuesday, August 08, 2017 2:55 AM
To: jihun.ha@...; edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

In my understanding, the rules engine is really an export service client since it always registers itself as an Export Client by means of the Export Client Registration microservice automatically. So it can receive all events and readings through the Export Distribution microservice. Across different EdgeX nodes they communicate ZeroMQ and plus gateway ActiveMQ, instead of container.

Thanks

Tiejun

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Tuesday, August 8, 2017 8:35 AM
To: edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To:
edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

Drasko DRASKOVIC
 

Hello Tiejun

On Wed, Aug 9, 2017 at 9:31 AM, Tiejun Chen <tiejunc@...> wrote:

Jim,

Thank you for your elaboration on it. Yes, from https://wiki.edgexfoundry.org , I noticed there is another sort of quick path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since we’re trying to deploy EdgeX on VM residing on IoT gateway. You know, under hypervisor we can install multiple VMs on one IoT Gateway so that means we can deploy several EdgeX nodes on one IoT Gateway. So I think we keep Core Services Layer, Supporting Services Layer and Device Services Layer within one VM but probably bring Export Service Layer into another VM, because just Export Service Layer mostly interacts with external like off-gaterway client, or distributed on-gateway client for other telnet. It’s getting a risk of being attached. So if we can isolate it, we can protect other basic layers to make sure EdgeX can continue working in some ways.
I think that will bring you much complexity (on the networking side.
And kernel updates will probably also be a mess) for a very little
benefit.

All EdgeX services are being run in (practically) completely isolated
environments, i.e. Docker containers. There has been a lot of work
done on Docker container security, and popularity of containers rises
so we can expect them soon to be bigger than VMs. So, I think your
investigation should start with articles like these:
http://www.infoworld.com/article/3071679/linux/linux-containers-vs-vms-a-security-comparison.html
and a question "Would a VM be more secure than a Docker container in
this particular use-case". My opinion is that it would not (especially
that there are various techniques to make containers more secure), but
I would like to hear the arguments against.

Also, have in mind that these containers have to me monitored (and
eventually restarted by watchdog/supervisor), and that there is
already a great set of tools for container orchestration and
monitoring - take for example Kubernetes (which would probably be
overkill for this application on a single host, but never the less).

Best regards,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Tiejun Chen
 

-----Original Message-----
From: Drasko DRASKOVIC [mailto:drasko@...]
Sent: Thursday, August 10, 2017 5:55 AM
To: Tiejun Chen <tiejunc@...>
Cc: White, James (Dell) <James_White2@...>; jihun.ha@...;
edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

Hello Tiejun

On Wed, Aug 9, 2017 at 9:31 AM, Tiejun Chen <tiejunc@...> wrote:

Jim,

Thank you for your elaboration on it. Yes, from
https://urldefense.proofpoint.com/v2/url?u=https-
3A__wiki.edgexfoundry.org&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=07u
ia9Ug44gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=hpIxIQFeNHCZIiIHqdiUQYEVS0dnb-
zGiiRq9DLQfOk&s=17OAAMQkTtbSWSYrYo-
XdMmHNvokGCsHZCy2raK34ro&e= , I noticed there is another sort of quick
path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since
we’re trying to deploy EdgeX on VM residing on IoT gateway. You know,
under hypervisor we can install multiple VMs on one IoT Gateway so that
means we can deploy several EdgeX nodes on one IoT Gateway. So I think we
keep Core Services Layer, Supporting Services Layer and Device Services Layer
within one VM but probably bring Export Service Layer into another VM,
because just Export Service Layer mostly interacts with external like off-
gaterway client, or distributed on-gateway client for other telnet. It’s getting a
risk of being attached. So if we can isolate it, we can protect other basic layers
to make sure EdgeX can continue working in some ways.
Drasko,

Thank you for your comments.

I think that will bring you much complexity (on the networking side.
And kernel updates will probably also be a mess) for a very little benefit.
Yeah, it could bring out some complexities but I think it depends on the given scenarios. Here I'd like to put this in multiple tenants and security perspective.

But what do you mean? The networking side? Inter-VM communications should be versatile at this point. kernel updates will probably also be a mess? I cannot understand this so could you elaborate it?


All EdgeX services are being run in (practically) completely isolated
environments, i.e. Docker containers. There has been a lot of work done on
Yeah, all EdgeX services is packaged by container now but this doesn't mean we cannot use light weight VM to carry out (part of) EdgeX services.

Docker container security, and popularity of containers rises so we can expect
them soon to be bigger than VMs. So, I think your investigation should start
with articles like these:
https://urldefense.proofpoint.com/v2/url?u=http-
3A__www.infoworld.com_article_3071679_linux_linux-2Dcontainers-2Dvs-
2Dvms-2Da-2Dsecurity-
2Dcomparison.html&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=07uia9Ug4
4gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=hpIxIQFeNHCZIiIHqdiUQYEVS0dnb-
zGiiRq9DLQfOk&s=7mCaoBeBGsV89EAWjsZwCyGWYkk33jAdwOEUaO-
KtWQ&e=
and a question "Would a VM be more secure than a Docker container in this
particular use-case". My opinion is that it would not (especially that there are
various techniques to make containers more secure), but I would like to hear
the arguments against.
So far I don't agree with this. Firstly I'm focusing on Type 1 hypervisor since obviously Type 2 hypervisor is affected easily by Host OS. At this point Type 2 is morel like container. All containers share one host OS so if something is wrong with host OS, other containers could be attacked. Do you remember Dirty-COW issue last year? That really makes containers to escape. Even you are running SELinux or Grsecurity. Maybe you want to mention something like SGX. But SGX (EPC) is limited, and if malware slips into enclave, nobody can handle it almost. Or just use EPT, it is not a whole solution to protect container...

Anyway, VM vs Container is a big question. I believe you have different opinion, but I think we can continue discussing this somewhere else 😊 Because it's out of EdgeX essential scope. So I just think here we shouldn't argue which one, VM or container, is winner. Instead, we should raise some questions like, could we make EdgX better with hardware virtualization? How can we fit EdgeX into virtualized edge devices?

Right here our goal is trying to explore what could be done better based on hardware virtualization & EdgeX at the edge side, in terms of edge computing. Under hardware virtualization, it's worthy to look into if multiple EdgeX nodes can work efficiently and securely onto edge devices. I also hope we can make EdgeX as hypervisor agnostic.

Also, have in mind that these containers have to me monitored (and
eventually restarted by watchdog/supervisor), and that there is already a
great set of tools for container orchestration and monitoring - take for
example Kubernetes (which would probably be overkill for this application on
a single host, but never the less).
Don't worry. I'm not sure if you have heard Container-as-a-VM like VMware's Vsphere Integrated Container, and hyper.sh. Those set of tools for container orchestrations and monitoring still can work. Furthermore, you can image we can take more tools and facilities as VM

Thanks
Tiejun


Best regards,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.linkedin.com_in_draskodraskovic&d=DwIFaQ&c=uilaK90D4TOVoH
58JNXRgQ&r=07uia9Ug44gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=hpIxIQFeNHCZIiIHqdiUQYEVS0dnb-
zGiiRq9DLQfOk&s=oPdjDCO5Phlw3wbiy_LMkZ1N3epL0F1LOXEaX1Y7A-g&e=
Twitter: @draskodraskovic

Tiejun Chen
 

Jim,

I think it’s not only neat. More accurately, we are trying to explore how to make EdgeX work well on virtualized edge devices. For example, we probably have multiple tenants on one virtualized IoT Gateway. We separate them with different VMs.

Yes, I’d like to discuss this more with EdgeX security working group. Does EdgeX security working group have a separate email list?

Thanks

Tiejun

 

From: James_White2@... [mailto:James_White2@...]
Sent: Wednesday, August 9, 2017 9:46 PM
To: Tiejun Chen <tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Tiejun,

Sounds like some neat work.  The microservices approach allows for these kinds of considerations and distribution – perfect!  At this point, you are out in front of some of us in thinking about certain distribution and deployment concerns, but that is great and your work can help identify issues we need to address.  You may also want to tie in with the EdgeX security working group as some of the isolation / separation concerns are things they want to address and they might have ideas that could address some of your concerns (and vice versa).

Jim

From: Chen, Tiejun (VMware)
Sent: Wednesday, August 09, 2017 2:32 AM
To: White2, James <James_White2@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Jim,

Thank you for your elaboration on it. Yes, from https://wiki.edgexfoundry.org , I noticed there is another sort of quick path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since we’re trying to deploy EdgeX on VM residing on IoT gateway. You know, under hypervisor we can install multiple VMs on one IoT Gateway so that means we can deploy several EdgeX nodes on one IoT Gateway. So I think we keep Core Services Layer, Supporting Services Layer and Device Services Layer within one VM but probably bring Export Service Layer into another VM, because just Export Service Layer mostly interacts with external like off-gaterway client, or distributed on-gateway client for other telnet. It’s getting a risk of being attached. So if we can isolate it, we can protect other basic layers to make sure EdgeX can continue working in some ways.

Overall, it looks like the big picture including some following items in my mind.

  • Isolate and separate Export Service Layer
  • Trim down EdgeX to make sure it can be customized only to have necessary components to one given telnet
  • Construct light weight VM to carry out EdgeX
  • Provide secure inter-VM channel between Export Services Layer and other layers
  • Others

Any comments will be appreciated.

Thanks

Tiejun

From: James_White2@... [mailto:James_White2@...]
Sent: Tuesday, August 8, 2017 10:36 PM
To: Tiejun Chen <tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Hi Tiejun,

You are correct – by default, the rules engine is a registered client of the export distribution service and receives all data coming up through core data via the export distribution service.  However, there are configuration options in EdgeX that allows core data to send data directly to the rules engine (and bypass the export distribution service).  This has pluses/minuses associated with it.

The export distribution service has the ability (the responsibility) to filter, transform, format, etc. the data for any application (like analytics engines or rules engines) or the cloud, enterprise system, or next level of the fog hierarchy.  So bypassing this layer, means the rules engine (or any service) is getting the raw data from core data and must take on these responsibilities on its own.

The reason for the direct feed option is to enable a quicker feed of the data to edge intelligence systems (rules engine, analytics, etc.) for those more near-real time needs (for example, you may want the motor actuation to happen quicker when the engine is determined to have some anomaly that requires immediate shutdown).  Indeed, if there is no need to pass the data further than the local edge node, the export services may actually be removed.

Across EdgeX nodes, we don’t yet have a formal orchestration means to get data across nodes, but the export services (with client registration and distribution service) can be used to have an analytics capability (or a rules engine micro service) on another EdgeX platform to register for the data from another instance of EdgeX.

Jim

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of Chen, Tiejun (VMware)
Sent: Tuesday, August 08, 2017 2:55 AM
To: jihun.ha@...; edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

In my understanding, the rules engine is really an export service client since it always registers itself as an Export Client by means of the Export Client Registration microservice automatically. So it can receive all events and readings through the Export Distribution microservice. Across different EdgeX nodes they communicate ZeroMQ and plus gateway ActiveMQ, instead of container.

Thanks

Tiejun

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Tuesday, August 8, 2017 8:35 AM
To: edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To:
edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

Drasko DRASKOVIC
 

Hi Tiejun,

On Thu, Aug 10, 2017 at 8:39 AM, Tiejun Chen <tiejunc@...> wrote:

Jim,

I think it’s not only neat. More accurately, we are trying to explore how to make EdgeX work well on virtualized edge devices. For example, we probably have multiple tenants on one virtualized IoT Gateway. We separate them with different VMs.

Yes, I’d like to discuss this more with EdgeX security working group. Does EdgeX security working group have a separate email list?
You can find dev resources on our project page:
https://www.edgexfoundry.org/developers/.

You'll find over there also a link to available mailing-lists:
https://lists.edgexfoundry.org/mailman/listinfo

BR,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Tiejun Chen
 

Thanks very much!

Tiejun

-----Original Message-----
From: Drasko DRASKOVIC [mailto:drasko@...]
Sent: Thursday, August 10, 2017 2:46 PM
To: Tiejun Chen <tiejunc@...>
Cc: White, James (Dell) <James_White2@...>; jihun.ha@...;
edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

Hi Tiejun,

On Thu, Aug 10, 2017 at 8:39 AM, Tiejun Chen <tiejunc@...> wrote:

Jim,

I think it’s not only neat. More accurately, we are trying to explore how to
make EdgeX work well on virtualized edge devices. For example, we probably
have multiple tenants on one virtualized IoT Gateway. We separate them with
different VMs.

Yes, I’d like to discuss this more with EdgeX security working group. Does
EdgeX security working group have a separate email list?

You can find dev resources on our project page:
https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.edgexfoundry.org_developers_&d=DwIFaQ&c=uilaK90D4TOVoH58
JNXRgQ&r=07uia9Ug44gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=Y3zIM8UX05lvFt-b0Fc-
vDXIACt7VxIfOI4eKW_mzBM&s=xA8_xDVTrpMHpiGRBs3MNyK2lUJ3hl2XYAXl
DRGpL3Y&e= .

You'll find over there also a link to available mailing-lists:
https://urldefense.proofpoint.com/v2/url?u=https-
3A__lists.edgexfoundry.org_mailman_listinfo&d=DwIFaQ&c=uilaK90D4TOVo
H58JNXRgQ&r=07uia9Ug44gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=Y3zIM8UX05lvFt-b0Fc-
vDXIACt7VxIfOI4eKW_mzBM&s=5Nl2Z-LW8I-jg8y3dL5amkQq-2quAftEtXE-
jEcfk3c&e=

BR,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.linkedin.com_in_draskodraskovic&d=DwIFaQ&c=uilaK90D4TOVoH
58JNXRgQ&r=07uia9Ug44gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=Y3zIM8UX05lvFt-b0Fc-
vDXIACt7VxIfOI4eKW_mzBM&s=lVBgJ-GFReBT7Nmkw-
JLlDu9w4_582XqwoLHnCwW_3E&e=
Twitter: @draskodraskovic

Drasko DRASKOVIC
 

Hi Tiejun

On Thu, Aug 10, 2017 at 8:32 AM, Tiejun Chen <tiejunc@...> wrote:
-----Original Message-----
From: Drasko DRASKOVIC [mailto:drasko@...]
Sent: Thursday, August 10, 2017 5:55 AM
To: Tiejun Chen <tiejunc@...>
Cc: White, James (Dell) <James_White2@...>; jihun.ha@...;
edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

Hello Tiejun

On Wed, Aug 9, 2017 at 9:31 AM, Tiejun Chen <tiejunc@...> wrote:

Jim,

Thank you for your elaboration on it. Yes, from
https://urldefense.proofpoint.com/v2/url?u=https-
3A__wiki.edgexfoundry.org&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=07u
ia9Ug44gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=hpIxIQFeNHCZIiIHqdiUQYEVS0dnb-
zGiiRq9DLQfOk&s=17OAAMQkTtbSWSYrYo-
XdMmHNvokGCsHZCy2raK34ro&e= , I noticed there is another sort of quick
path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since
we’re trying to deploy EdgeX on VM residing on IoT gateway. You know,
under hypervisor we can install multiple VMs on one IoT Gateway so that
means we can deploy several EdgeX nodes on one IoT Gateway. So I think we
keep Core Services Layer, Supporting Services Layer and Device Services Layer
within one VM but probably bring Export Service Layer into another VM,
because just Export Service Layer mostly interacts with external like off-
gaterway client, or distributed on-gateway client for other telnet. It’s getting a
risk of being attached. So if we can isolate it, we can protect other basic layers
to make sure EdgeX can continue working in some ways.
Drasko,

Thank you for your comments.

I think that will bring you much complexity (on the networking side.
And kernel updates will probably also be a mess) for a very little benefit.
Yeah, it could bring out some complexities but I think it depends on the given scenarios. Here I'd like to put this in multiple tenants and security perspective.

But what do you mean? The networking side? Inter-VM communications should be versatile at this point. kernel updates will probably also be a mess? I cannot understand this so could you elaborate it?
Well - I see a scenario where some other services are in charge with
updating Linux stuff - for example U-Boot on an embedded ARM board.
Since you have so many firmware update strategies, it is out of domain
of EdgeX project, which deals only with EdgeX components updates. Now
- if you are to replace the kernel by choosing one strategy for your
board, hat will you do for VMs? Change kernel in each of them one by
one? This is what I meant - an additional complexity of the system.



All EdgeX services are being run in (practically) completely isolated
environments, i.e. Docker containers. There has been a lot of work done on
Yeah, all EdgeX services is packaged by container now but this doesn't mean we cannot use light weight VM to carry out (part of) EdgeX services.

Docker container security, and popularity of containers rises so we can expect
them soon to be bigger than VMs. So, I think your investigation should start
with articles like these:
https://urldefense.proofpoint.com/v2/url?u=http-
3A__www.infoworld.com_article_3071679_linux_linux-2Dcontainers-2Dvs-
2Dvms-2Da-2Dsecurity-
2Dcomparison.html&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=07uia9Ug4
4gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=hpIxIQFeNHCZIiIHqdiUQYEVS0dnb-
zGiiRq9DLQfOk&s=7mCaoBeBGsV89EAWjsZwCyGWYkk33jAdwOEUaO-
KtWQ&e=
and a question "Would a VM be more secure than a Docker container in this
particular use-case". My opinion is that it would not (especially that there are
various techniques to make containers more secure), but I would like to hear
the arguments against.
So far I don't agree with this. Firstly I'm focusing on Type 1 hypervisor since obviously Type 2 hypervisor is affected easily by Host OS. At this point Type 2 is morel like container. All containers share one host OS so if something is wrong with host OS, other containers could be attacked. Do you remember Dirty-COW issue last year? That really makes containers to escape. Even you are running SELinux or Grsecurity. Maybe you want to mention something like SGX. But SGX (EPC) is limited, and if malware slips into enclave, nobody can handle it almost. Or just use EPT, it is not a whole solution to protect container...

Anyway, VM vs Container is a big question. I believe you have different opinion, but I think we can continue discussing this somewhere else 😊 Because it's out of EdgeX essential scope. So I just think here we shouldn't argue which one, VM or container, is winner. Instead, we should raise some questions like, could we make EdgX better with hardware virtualization? How can we fit EdgeX into virtualized edge devices?

Right here our goal is trying to explore what could be done better based on hardware virtualization & EdgeX at the edge side, in terms of edge computing. Under hardware virtualization, it's worthy to look into if multiple EdgeX nodes can work efficiently and securely onto edge devices. I also hope we can make EdgeX as hypervisor agnostic.

Also, have in mind that these containers have to me monitored (and
eventually restarted by watchdog/supervisor), and that there is already a
great set of tools for container orchestration and monitoring - take for
example Kubernetes (which would probably be overkill for this application on
a single host, but never the less).
Don't worry. I'm not sure if you have heard Container-as-a-VM like VMware's Vsphere Integrated Container, and hyper.sh. Those set of tools for container orchestrations and monitoring still can work. Furthermore, you can image we can take more tools and facilities as VM
Great, I think that the work of exploring Type-1 hypervisors would be
very valuable, especially because I am not aware of any other EdgeX
group exploring it.

I also see a value in virtualization (even if it is Type-2) as NFV
functions are sent today via VMs (at least it is the case of OPNFV
project which uses OpenStack -
https://www.opnfv.org/community/upstream-projects/openstack).

Best regards,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Tiejun Chen
 

[snip]

we’re trying to deploy EdgeX on VM residing on IoT gateway. You know,
under hypervisor we can install multiple VMs on one IoT Gateway so
that means we can deploy several EdgeX nodes on one IoT Gateway. So I
think we keep Core Services Layer, Supporting Services Layer and
Device Services Layer within one VM but probably bring Export Service
Layer into another VM, because just Export Service Layer mostly
interacts with external like off- gaterway client, or distributed
on-gateway client for other telnet. It’s getting a risk of being
attached. So if we can isolate it, we can protect other basic layers to make
sure EdgeX can continue working in some ways.
Drasko,

Thank you for your comments.

I think that will bring you much complexity (on the networking side.
And kernel updates will probably also be a mess) for a very little benefit.
Yeah, it could bring out some complexities but I think it depends on the
given scenarios. Here I'd like to put this in multiple tenants and security
perspective.

But what do you mean? The networking side? Inter-VM communications
should be versatile at this point. kernel updates will probably also be a mess?
I cannot understand this so could you elaborate it?

Well - I see a scenario where some other services are in charge with updating
Linux stuff - for example U-Boot on an embedded ARM board.
Since you have so many firmware update strategies, it is out of domain of
EdgeX project, which deals only with EdgeX components updates. Now
- if you are to replace the kernel by choosing one strategy for your board, hat
will you do for VMs? Change kernel in each of them one by one? This is what I
meant - an additional complexity of the system.
You mean user define his own service by means of EdgeX to update firmware like bootloader. Sounds like you're taking about OTA, Over The Air. Yes, you can have many firmware strategies as normal but you don’t have conflictive strategies for one firmware. So with virtualization, it's treated as access shared resource and Hypervisor can intercept this access to go appropriate behavior, according to user policy. We can sync up this update across multiple EdgeX nodes.




All EdgeX services are being run in (practically) completely isolated
environments, i.e. Docker containers. There has been a lot of work
done on
Yeah, all EdgeX services is packaged by container now but this doesn't mean
we cannot use light weight VM to carry out (part of) EdgeX services.

Docker container security, and popularity of containers rises so we
can expect them soon to be bigger than VMs. So, I think your
investigation should start with articles like these:
https://urldefense.proofpoint.com/v2/url?u=http-
3A__www.infoworld.com_article_3071679_linux_linux-2Dcontainers-2Dvs-
2Dvms-2Da-2Dsecurity-
2Dcomparison.html&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=07uia9Ug4
4gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=hpIxIQFeNHCZIiIHqdiUQYEVS0dnb-
zGiiRq9DLQfOk&s=7mCaoBeBGsV89EAWjsZwCyGWYkk33jAdwOEUaO-
KtWQ&e=
and a question "Would a VM be more secure than a Docker container in
this particular use-case". My opinion is that it would not
(especially that there are various techniques to make containers more
secure), but I would like to hear the arguments against.
So far I don't agree with this. Firstly I'm focusing on Type 1 hypervisor since
obviously Type 2 hypervisor is affected easily by Host OS. At this point Type 2
is morel like container. All containers share one host OS so if something is
wrong with host OS, other containers could be attacked. Do you remember
Dirty-COW issue last year? That really makes containers to escape. Even you
are running SELinux or Grsecurity. Maybe you want to mention something like
SGX. But SGX (EPC) is limited, and if malware slips into enclave, nobody can
handle it almost. Or just use EPT, it is not a whole solution to protect
container...

Anyway, VM vs Container is a big question. I believe you have different
opinion, but I think we can continue discussing this somewhere else 😊 Because
it's out of EdgeX essential scope. So I just think here we shouldn't argue which
one, VM or container, is winner. Instead, we should raise some questions like,
could we make EdgX better with hardware virtualization? How can we fit
EdgeX into virtualized edge devices?

Right here our goal is trying to explore what could be done better based on
hardware virtualization & EdgeX at the edge side, in terms of edge computing.
Under hardware virtualization, it's worthy to look into if multiple EdgeX nodes
can work efficiently and securely onto edge devices. I also hope we can make
EdgeX as hypervisor agnostic.

Also, have in mind that these containers have to me monitored (and
eventually restarted by watchdog/supervisor), and that there is
already a great set of tools for container orchestration and
monitoring - take for example Kubernetes (which would probably be
overkill for this application on a single host, but never the less).
Don't worry. I'm not sure if you have heard Container-as-a-VM like
VMware's Vsphere Integrated Container, and hyper.sh. Those set of
tools for container orchestrations and monitoring still can work.
Furthermore, you can image we can take more tools and facilities as VM
Great, I think that the work of exploring Type-1 hypervisors would be very
valuable, especially because I am not aware of any other EdgeX group
exploring it.
We are at the earlier stage so if you have any thought of virtualization & IoT Edge Device like IoT Gateway, please let me know. I hope we can construct one real use case and if we can bring EdgeX into this sort of PoC, things couldn't be better.


I also see a value in virtualization (even if it is Type-2) as NFV functions are
sent today via VMs (at least it is the case of OPNFV project which uses
OpenStack - https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.opnfv.org_community_upstream-
2Dprojects_openstack&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=07uia9Ug
44gDTos4Skoc-UHWYOhje6rSAfMw5lKjUlo&m=PQCdcODf-
TtHu6ium4arBU0zDkpKSs3ihrHnhkqXIQY&s=3B-
UyVcadXVdbmCTkSaGt8GFMA2zkAEMwpih87Yi_EM&e= ).
Yes, in terms of cloud, or Fog cloud, you can find these kind of examples but now we want to pay attention to Edge Computing. We can explore how to do edge computing with edge devices. 😊

Thanks
Tiejun


Best regards,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.linkedin.com_in_draskodraskovic&d=DwIFaQ&c=uilaK90D4TOVoH
58JNXRgQ&r=07uia9Ug44gDTos4Skoc-
UHWYOhje6rSAfMw5lKjUlo&m=PQCdcODf-
TtHu6ium4arBU0zDkpKSs3ihrHnhkqXIQY&s=7keE59n6tXcyA1UxyewMI9e269u
sBKQbNXOmFffY47I&e=
Twitter: @draskodraskovic

Drasko DRASKOVIC
 

On Thu, Aug 10, 2017 at 10:40 AM, Tiejun Chen <tiejunc@...> wrote:

You mean user define his own service by means of EdgeX to update firmware like bootloader. Sounds like you're taking about OTA, Over The Air. Yes, you can have many firmware strategies as normal but you don’t have conflictive strategies for one firmware. So with virtualization, it's treated as access shared resource and Hypervisor can intercept this access to go appropriate behavior, according to user policy. We can sync up this update across multiple EdgeX nodes.
I meant about low-level (bootloader and kernel) OTA updates. In which
kernel which holds Type-2 hypervisors would be replaced. And I guess
scenario in which Type-1 hypervisors would be replaced.

Or in other words - today all EdgeX microservices (containers) run on
one kernel (host). In your versions they would run on several kernels
(virtualized hosts). Changing the underlying kernel in your case would
demand more work (keeping kernels in all VMs in sync), and you'll also
have a specific requirements for updating baremetal code (which,
again, is out of scope of EdgeX project, but we'll give some best
recommendations for typical use-cases)

We are at the earlier stage so if you have any thought of virtualization & IoT Edge Device like IoT Gateway, please let me know. I hope we can construct one real use case and if we can bring EdgeX into this sort of PoC, things couldn't be better.
I think this can be highly beneficial mutually - for you and EdgeX
community. With EdgeX Foundry there is a clear ambition to set this SW
system as a first choice for IoT Edge devices, something that
hopefully we'll see on every industrial device of this kind, so that
once project gains in the popularity no producer would like to be left
out of the game.

BR,
Drasko DRASKOVIC
Mainflux CTO & Co-Founder

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

James.White2@...
 

Dell - Internal Use - Confidential

Tiejun,

Yes they have a separate mailing list, rocket chat channel and working group meeting time.  You can get find the mailing list and get signed up to the working group meetings via the Developer page on the main web site.  You can also reach out to Brett Preston, copied, to get added to the invite list for the working group.  In fact, they are planning a face-to-face meeting at the end of August in California.

jim

From: Chen, Tiejun (VMware)
Sent: Thursday, August 10, 2017 1:39 AM
To: White2, James <James_White2@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Jim,

I think it’s not only neat. More accurately, we are trying to explore how to make EdgeX work well on virtualized edge devices. For example, we probably have multiple tenants on one virtualized IoT Gateway. We separate them with different VMs.

Yes, I’d like to discuss this more with EdgeX security working group. Does EdgeX security working group have a separate email list?

Thanks

Tiejun

 

From: James_White2@... [mailto:James_White2@...]
Sent: Wednesday, August 9, 2017 9:46 PM
To: Tiejun Chen <tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Tiejun,

Sounds like some neat work.  The microservices approach allows for these kinds of considerations and distribution – perfect!  At this point, you are out in front of some of us in thinking about certain distribution and deployment concerns, but that is great and your work can help identify issues we need to address.  You may also want to tie in with the EdgeX security working group as some of the isolation / separation concerns are things they want to address and they might have ideas that could address some of your concerns (and vice versa).

Jim

From: Chen, Tiejun (VMware)
Sent: Wednesday, August 09, 2017 2:32 AM
To: White2, James <James_White2@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Jim,

Thank you for your elaboration on it. Yes, from https://wiki.edgexfoundry.org , I noticed there is another sort of quick path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since we’re trying to deploy EdgeX on VM residing on IoT gateway. You know, under hypervisor we can install multiple VMs on one IoT Gateway so that means we can deploy several EdgeX nodes on one IoT Gateway. So I think we keep Core Services Layer, Supporting Services Layer and Device Services Layer within one VM but probably bring Export Service Layer into another VM, because just Export Service Layer mostly interacts with external like off-gaterway client, or distributed on-gateway client for other telnet. It’s getting a risk of being attached. So if we can isolate it, we can protect other basic layers to make sure EdgeX can continue working in some ways.

Overall, it looks like the big picture including some following items in my mind.

  • Isolate and separate Export Service Layer
  • Trim down EdgeX to make sure it can be customized only to have necessary components to one given telnet
  • Construct light weight VM to carry out EdgeX
  • Provide secure inter-VM channel between Export Services Layer and other layers
  • Others

Any comments will be appreciated.

Thanks

Tiejun

From: James_White2@... [mailto:James_White2@...]
Sent: Tuesday, August 8, 2017 10:36 PM
To: Tiejun Chen <tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Hi Tiejun,

You are correct – by default, the rules engine is a registered client of the export distribution service and receives all data coming up through core data via the export distribution service.  However, there are configuration options in EdgeX that allows core data to send data directly to the rules engine (and bypass the export distribution service).  This has pluses/minuses associated with it.

The export distribution service has the ability (the responsibility) to filter, transform, format, etc. the data for any application (like analytics engines or rules engines) or the cloud, enterprise system, or next level of the fog hierarchy.  So bypassing this layer, means the rules engine (or any service) is getting the raw data from core data and must take on these responsibilities on its own.

The reason for the direct feed option is to enable a quicker feed of the data to edge intelligence systems (rules engine, analytics, etc.) for those more near-real time needs (for example, you may want the motor actuation to happen quicker when the engine is determined to have some anomaly that requires immediate shutdown).  Indeed, if there is no need to pass the data further than the local edge node, the export services may actually be removed.

Across EdgeX nodes, we don’t yet have a formal orchestration means to get data across nodes, but the export services (with client registration and distribution service) can be used to have an analytics capability (or a rules engine micro service) on another EdgeX platform to register for the data from another instance of EdgeX.

Jim

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of Chen, Tiejun (VMware)
Sent: Tuesday, August 08, 2017 2:55 AM
To: jihun.ha@...; edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

In my understanding, the rules engine is really an export service client since it always registers itself as an Export Client by means of the Export Client Registration microservice automatically. So it can receive all events and readings through the Export Distribution microservice. Across different EdgeX nodes they communicate ZeroMQ and plus gateway ActiveMQ, instead of container.

Thanks

Tiejun

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Tuesday, August 8, 2017 8:35 AM
To: edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To:
edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

Tiejun Chen
 

Jim,

Actually I’ve already subscribed edgex-tsc-security@.  Thank you!

Just BTW, looks you’re seeking EdgeX demos from any voluntary company at Barcelona IoT, right? So what kind of demo can be allows to demonstrate right there? Any particular requirement?

Thanks

Tiejun

 

From: James_White2@... [mailto:James_White2@...]
Sent: Thursday, August 10, 2017 9:29 PM
To: Tiejun Chen <tiejunc@...>; jihun.ha@...; edgex-devel@...
Cc: bpreston@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Tiejun,

Yes they have a separate mailing list, rocket chat channel and working group meeting time.  You can get find the mailing list and get signed up to the working group meetings via the Developer page on the main web site.  You can also reach out to Brett Preston, copied, to get added to the invite list for the working group.  In fact, they are planning a face-to-face meeting at the end of August in California.

jim

From: Chen, Tiejun (VMware)
Sent: Thursday, August 10, 2017 1:39 AM
To: White2, James <
James_White2@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Jim,

I think it’s not only neat. More accurately, we are trying to explore how to make EdgeX work well on virtualized edge devices. For example, we probably have multiple tenants on one virtualized IoT Gateway. We separate them with different VMs.

Yes, I’d like to discuss this more with EdgeX security working group. Does EdgeX security working group have a separate email list?

Thanks

Tiejun

 

From: James_White2@... [mailto:James_White2@...]
Sent: Wednesday, August 9, 2017 9:46 PM
To: Tiejun Chen <
tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Tiejun,

Sounds like some neat work.  The microservices approach allows for these kinds of considerations and distribution – perfect!  At this point, you are out in front of some of us in thinking about certain distribution and deployment concerns, but that is great and your work can help identify issues we need to address.  You may also want to tie in with the EdgeX security working group as some of the isolation / separation concerns are things they want to address and they might have ideas that could address some of your concerns (and vice versa).

Jim

From: Chen, Tiejun (VMware)
Sent: Wednesday, August 09, 2017 2:32 AM
To: White2, James <
James_White2@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Jim,

Thank you for your elaboration on it. Yes, from https://wiki.edgexfoundry.org , I noticed there is another sort of quick path addressing time-sensitive cases. It really makes sense at this point.

BTW, we’re also exploring if we can separate these four service layers since we’re trying to deploy EdgeX on VM residing on IoT gateway. You know, under hypervisor we can install multiple VMs on one IoT Gateway so that means we can deploy several EdgeX nodes on one IoT Gateway. So I think we keep Core Services Layer, Supporting Services Layer and Device Services Layer within one VM but probably bring Export Service Layer into another VM, because just Export Service Layer mostly interacts with external like off-gaterway client, or distributed on-gateway client for other telnet. It’s getting a risk of being attached. So if we can isolate it, we can protect other basic layers to make sure EdgeX can continue working in some ways.

Overall, it looks like the big picture including some following items in my mind.

  • Isolate and separate Export Service Layer
  • Trim down EdgeX to make sure it can be customized only to have necessary components to one given telnet
  • Construct light weight VM to carry out EdgeX
  • Provide secure inter-VM channel between Export Services Layer and other layers
  • Others

Any comments will be appreciated.

Thanks

Tiejun

From: James_White2@... [mailto:James_White2@...]
Sent: Tuesday, August 8, 2017 10:36 PM
To: Tiejun Chen <
tiejunc@...>; jihun.ha@...; edgex-devel@...
Subject: RE: [Edgex-devel] Communication ways between EXF devices

 

Hi Tiejun,

You are correct – by default, the rules engine is a registered client of the export distribution service and receives all data coming up through core data via the export distribution service.  However, there are configuration options in EdgeX that allows core data to send data directly to the rules engine (and bypass the export distribution service).  This has pluses/minuses associated with it.

The export distribution service has the ability (the responsibility) to filter, transform, format, etc. the data for any application (like analytics engines or rules engines) or the cloud, enterprise system, or next level of the fog hierarchy.  So bypassing this layer, means the rules engine (or any service) is getting the raw data from core data and must take on these responsibilities on its own.

The reason for the direct feed option is to enable a quicker feed of the data to edge intelligence systems (rules engine, analytics, etc.) for those more near-real time needs (for example, you may want the motor actuation to happen quicker when the engine is determined to have some anomaly that requires immediate shutdown).  Indeed, if there is no need to pass the data further than the local edge node, the export services may actually be removed.

Across EdgeX nodes, we don’t yet have a formal orchestration means to get data across nodes, but the export services (with client registration and distribution service) can be used to have an analytics capability (or a rules engine micro service) on another EdgeX platform to register for the data from another instance of EdgeX.

Jim

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of Chen, Tiejun (VMware)
Sent: Tuesday, August 08, 2017 2:55 AM
To:
jihun.ha@...; edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

In my understanding, the rules engine is really an export service client since it always registers itself as an Export Client by means of the Export Client Registration microservice automatically. So it can receive all events and readings through the Export Distribution microservice. Across different EdgeX nodes they communicate ZeroMQ and plus gateway ActiveMQ, instead of container.

Thanks

Tiejun

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Tuesday, August 8, 2017 8:35 AM
To:
edgex-devel@...
Subject: Re: [Edgex-devel] Communication ways between EXF devices

 

Hello. Jim White.

 

Thank you for you detailed explanation. I can understand how an EXF device can get a data from other EXF device.

BTW, I have one more question.

Can a microservice(e.g. rule engine service) in an EXF device directly access to distribution service of other EXF device?

Because, all containers in an EXF device communicate to each other above a bridge network, named edgex-network, so it is hard to communicate between two containers in different EXF devices as far as I know.

For that, do we have to use other network configuration like overlay network by utilizing Docker swarm mode? or Am I misunderstanding a capability of a bridge network in docker?

 

Thank you.

BR. Jihun Ha.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : James.White2@... <James.White2@...>

Date : 2017-08-07 22:59 (GMT+9)

Title : RE: [Edgex-devel] Communication ways between EXF devices

 

Dell - Internal Use - Confidential

Hi Jihun,

We are excited to have Samsung in the project!

Let me see if I can answer your questions…

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

Yes – you have a proper understanding of the basic architecture.  An OPC-UA Device Service microservice in this example would collect the sensor data and communicate that into our Core Services at which point, it is then made available to the Export Services (one of which is the export distribution  microservice) for any filtering, transformation, compression, encryption, formatting options to then be send to “client” endpoints.  Client endpoints could be cloud systems (like Azure IoT), or your own enterprise systems, or another node within a hierarchical fog deployment.

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

The export client micro service is used by any system (be it a second Edge device, a cloud provider, an entprise system, etc.) to register for data coming through EdgeX.  The export client registers clients for data requests and the export distribution microservice gets the data to the concerned clients (via either REST, MQTT, or ZeroMQ today). 

There is also an API around core data microservice so that any client can also make queries directly of the persisted sensor data – although we would discourage too much of this as it could tend to slow down the processing of data up from sensors/devices.

Hope this answers your questions Jihua.  Again, welcome to the project and we look forward to your participation.

Jim White

Distinguished Engineer, Software Architect

Project Fuse (now EdgeX Foundry) Chief Architect

Dell | End User Computing, Chief Technology Office (EUC CTO)

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of ???
Sent: Monday, August 07, 2017 12:35 AM
To:
edgex-devel@...
Subject: [Edgex-devel] Communication ways between EXF devices

 

Greetings,

 

I'm Jihun Ha from Samsung and excited to join EdgeX opensource to develop a software platform together for in-factory edge device :)

 

BTW, looking into a microservice architecture, called EXF, I got a question for ways how to communicate two different EXF-compatible devices.

 

For example, a first Edge device collects a bunch of sensor data through OPC-UA device service corresponding to a certain OPC-UA device, and performs a simple pre-processing in one of supporting service. And then, if my understanding is correct, the processed sensor data can be transmitted through "distribution service" to outside device.

 

At this time, if a second Edge device wants to subscribe the processed data transmitted from the first Edge device, which microservice in EXF is responsible for that communication? Distribution service OR other device service for communicating between EXF device?

 

I'd appreciate if anyone can give a clue for my question :)

 

Thank you.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

IoT, IoTivity, OIC | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com