amrc-factoryplus / acs-edge Goto Github PK

We need to test every connection type under the V3 deployment. This can just be a test connection made from the dev cluster but we need to confirm there are no regressions in the deployment.

Current status:

• MQTT: 👍
• OPC-UA: 👍
• REST: 👍
• S7: 👍
• UDP: don't care
• MTConnect: don't care
• Open Protocol: don't care
• ASCII TCP: don't care
• Ethernet/IP: 👍

We have a number of Raspberry Pis in our current internal deployment; given that they run k3s perfectly well it would be desirable to avoid needing to deploy another piece of hardware just to run the Edge Agent.

More generally, running ARM at the edge is likely to be an important requirement.

The UUIDs generated for the Alerts raised by the Edge Agent currently change every time the Edge Agent is restarted. This is not ideal, as the Directory has no way of knowing the new alert is a replacement for the old and will keep indexing both.

Since we have no information available to us except our own UPN, UUID and Sparkplug address, I propose using v5 UUIDs under the following scheme:

• Use the existing Factory+ UUID 11ad7b32-1d32-4c4a-b0c9-fa049208939a as the v5 UUID namespace.
• The name within this namespace is a string composed of colon separated parts.
• The first part is a subtype, also a UUID in canonical string format.
• The subtype 8a4dc2f4-2f9f-45fc-b2e9-ed7b9cda6145 is hereby reserved for generating Instance_UUIDs from fixed metric names.
• Names of this subtype have two more parts: a Device UUID and a string metric name.
• The metric name must be the folder prefix of the Instance_UUID metric we are generating.

So an alert based at Alerts/Config_Invalid for a device with uuid 11111111-2222-3333-4444-555555555555 would have a metric Alerts/Config_Invalid/Instance_UUID generated with

uuid.v5(
    "8a4dc2f4-2f9f-45fc-b2e9-ed7b9cda6145:11111111-2222-3333-4444-555555555555:Alerts/Config_Invalid",
    "11ad7b32-1d32-4c4a-b0c9-fa049208939a");

There is information in the config file that is no longer needed. Update the schema, and update the code to use the new schema.

The config schema needs loading into the ConfigDB under the Edge Config app UUID.

As the image is currently built the running code has no write access to /home/node/app. This is desirable from a security point of view.

The OPC-UA driver is trying to create a certificate store at /home/node/.config/node-opcua-default-nodejs/PKI. Probably the simplest solution is to mount an emtpyDir here? I don't think we really want to give the Edge Agent persistent storage unless we have to, it makes migration between machines a lot harder.

When having 2 devices that share the same S7 connection the second device metrics addresses overrides all s7Vars and the first device metrics do not get read.

Modbus TCP is far too popular as a protocol to keep it not in the app as a separate container (edge-modbus-rest).

• A syntax would need to be defined that would handle to aid reads.
• Modbus commonly requires the division of values by 10 or 100, this needs to be addressed at a higher level

When an S7 connection is wrong, it crashes the whole app.

Connection failure not handled well.

Logs:

DEBUG [2023-11-23T12:57:29.719Z] app.ts:57:5 --> Attempting to fetch config...
DEBUG [2023-11-23T12:57:30.144Z] app.ts:65:5 --> Config fetched.
DEBUG [2023-11-23T12:57:30.208Z] translator.ts:133:13 --> Created Sparkplug node "..." in group "...".
DEBUG [2023-11-23T12:57:30.209Z] translator.ts:135:13 --> Building up connections and devices...
Error: Unhandled error. (undefined)
    at new NodeError (node:internal/errors:405:5)
    at S7Connection.emit (node:events:506:17)
    at S7Endpoint.<anonymous> (file:///usr/lib/devices/S7.ts:57:18)
    at S7Endpoint.emit (node:events:529:35)
    at S7Endpoint._onTransportError (/usr/app/node_modules/@st-one-io/nodes7/src/s7endpoint.js:351:14)
    at /usr/app/node_modules/@st-one-io/nodes7/src/s7endpoint.js:190:28
    at processTicksAndRejections (node:internal/process/task_queues:95:5)