Designing Connected Industrial Equipment

Start from the fault a person must clear, not from a platform. What stopped, what is safe to touch, and what the machine will do next if nobody is watching the screen. Connectivity can shorten the time to that knowledge. It cannot be the only copy of it. Stage questions for the hardware are set out in Hardware Product Development Process Explained. The log sum below is invented teaching arithmetic, not a BrahmWorks capacity, price, yield or test result.

Write the local behaviour first, as if the radio were removed. Start, stop, fault, recovery, and the indication on the panel. If any of those moves to a remote button, say so as a safety decision, not as a feature. A remote start that can be pressed by someone who cannot see the machine is a different product from a remote reading. Most teams want the reading. The start needs a reason and a qualified look at the hazard. This article does not provide that look and states no safety rating.

Then choose the events worth sending. A stream of every internal bit will fill a store and a person's attention. An event with a name a maintainer uses, a time, and the small set of conditions that explain it, is usually enough. Agree the names with the people who clear the fault. A code that exists only in the vendor's head will be ignored, and the ignore will be blamed on "the connectivity".

Time has to be good enough for the question you are asking. Order of events on one machine is often what matters. Agreement with a wall clock across a site matters when you will compare machines. Write which of those you need. A clock that resets on power loss will invent a history. Say what the log does across that reset.

Keep a copy of the recent events on the machine. The network is then a way to read that copy, not the place the copy is born. Size the store for the failure you care about, not for a quiet average. A fault that chatters will write more in an hour than a healthy week. The labelled sum shows how large that difference is under assumptions you must replace.

The physical design still governs the connection. Antenna placement, a metal cabinet, a cable gland and a supply shared with a drive are hardware. A module taped inside a door for a pilot will not be the production path. Review it with the enclosure closed, because the door is part of the radio. Service access for the connector and the identity of the unit belong in the same review. A serial number that does not match the name in the log will waste the first real fault.

Provisioning is a factory or commissioning step. Each machine needs an identity applied on purpose, recorded against the mechanical and control revisions. A laptop ritual performed by the author is not commissioning. Write the step so the site can replace a unit without inventing a second identity for the same place in the line.

Do not remove the local indication because a remote view exists. The person at the machine may have no phone, no account or no signal. Do not let a lost message be displayed as a healthy machine. Stale has to look stale. Do not push a software update in a way that can stop a cycle you have not planned to stop. If updates exist, they are a controlled change with a defined machine state, not a background convenience.

Security here means the same practical points as any connected product, without a recipe for breaking one. Who may change a setting, how that authority is given at commissioning, and what happens if that material is copied. Details of attack are out of scope. The design point is that a default password shared across a site is a manufacturing choice, and it is a bad one.

A connected machine is not an automation product in the sense of a new station. The operation, the guards and the recovery should already be owned. Connectivity that arrives before those are owned will be asked to hide them. Refuse that job.

The teaching product is an existing press that already cycles. The new question is whether a maintainer can see, at the cabinet, why the last stop happened, and can see the same reason an hour later if the site network was down. It is not a BrahmWorks project and not a tested installation. No safety function is being moved.

In the build: a local log, a panel line a maintainer can read, an identity, and a path that copies the log out when the network returns. Out of the build: remote start, a rewrite of the press sequence, a cloud account for the whole company, and any claim about downtime reduced. If the panel says "fault" and the log says nothing because the network was down, the product has failed. The network was not supposed to be required for the sentence.

Forbidden conclusions: fewer stoppages, a security property you did not specify, and behaviour of any other machine. A pilot week in which the network happened to stay up does not answer the question you wrote.

These rates are assumed. They are not a measurement and not a BrahmWorks result.

Assume 80 bytes an event. Assume a quiet machine writes one event a minute. Over 14 days that is 14 times 24 times 60, which is 20,160 events. 20,160 times 80 is 1,612,800 bytes, about 1.6 million bytes.

Assume a chattering fault writes 20 events a minute, and assume you want two hours of that chatter kept. 20 times 120 minutes is 2,400 events. 2,400 times 80 is 192,000 bytes. The chatter alone is not the surprise. The surprise is believing the quiet fortnight, 1.6 million bytes, describes the machine you will debug. If the device keeps only 200,000 bytes, the quiet design looks fine for a short window and then throws away the chatter that explains the stop, or throws away the quiet context, depending on what you overwrite.

Decide what you overwrite. A ring that keeps the newest events will keep the chatter and lose the hour before it if the chatter is long. A ring that keeps the first events of a fault will do the opposite. Write the rule. Do not cite 1.6 million bytes as a requirement. Replace the rates with counts from the machine you are connecting.

• Start, stop, fault and recovery still work with the radio removed.
• Remote control of motion is either excluded or treated as its own safety scope.
• Event names are words the maintainer uses.
• The store is sized for the noisy fault, and the overwrite rule is written.
• Stale data cannot look healthy.
• Antenna, gland and identity are reviewed with the enclosure closed.
• A replacement unit can be commissioned from an instruction.
• Updates cannot stop a cycle by accident, or updates are absent.

You can add a reading at the end if the machine is already owned and the local fault remains clear. You cannot add it at the end if the cabinet, the supply and the service access were never going to allow it. Look at those before you promise a platform.

The indication and the recent reasons for a stop, including across a network outage and a power cycle if that cycle is part of the fault. The remote side may hold history. It should not hold the only copy of an explanation the person on the floor needs.

An automation product is the sequence and the station. Connected equipment, in this article, is an existing operation plus a careful report of state. Mixing them leads teams to "fix" a mechanical fault with a chart. The chart will not seat a part.

The order of the last events, whether the clock reset, and whether the figure is stale. A green tile averages those away. Put them on the panel in the same words as the log.

Bring the event list, the overwrite rule and a photograph of the indication when the cable is out. BrahmWorks can say whether the next build still leaves the machine in charge of its own explanation.

Review the next stage with BrahmWorks