Marrying Hardware and Software

Posted on May 10, 2017

By: David Pilkington, Software Developer

DEARLY beloved, we are gathered together here in the sight of Geeks, and in the face of these consumers, to join together this Hardware and this Software in peculiar Matrimony; which is a fickle estate, instituted of Developers in the time of man’s inquisitiveness, signifying unto us the mystical union that is betwixt Mechanics and Electronics; which unholy estate Physics concocted and bewildered with its presence, and first marvel that it wrought, in Silicon Valley of California; and is commended of Saint Morley to be honorable among all nerds: and therefore is not by any to be enterprised, nor taken in hand, unadvisedly, lightly, or haphazardly, to satisfy men’s curiosity and sense of achievement, like brute beasts that have no understanding; but reverently, discreetly, advisedly, soberly, and in the fear of accidental dismemberment; duly considering the causes for which Matrimony was ordained.

In pharmacy automation, there is a peculiar dance that hardware and software must do in order to fill, check, pack, and ship even one prescription. Just like a marriage between two people, components both mechanical and electronic must each faithfully fulfill their roles, all the while communicating clearly and in a timely manner. Else, the whole endeavor begins to fall apart and professional technical counselors are called in to repair the fabric of the relationship.

The partner named Hardware performs the physical labor. It is steely and strong, going through its repetitive motions with stamina and vigor. It does the heavy lifting, figuratively, and makes sure that things physically do what they’re supposed to do. It does what it does with resolve and purpose, guided by a great big brain called a Programmable Logic Controller (PLC). Despite, or more accurately because of, this brain, Hardware is stubborn; it does not like to deviate from its particular tasks.

The partner named Software, on the other hand, tells Hardware what to do and when to do it, though woe be to Software if it tries to tell Hardware how to do it. Software is organizationally minded, keeping every minute detail in its day planner named Database. Software remembers everything in perpetuity, recording everything it can in diaries it calls Log Files. Software likes to talk a lot; to Database, to other Softwares in the neighborhood, to the Almighty User, and yes, to Hardware.

There are many particular challenges that need to be addressed whenever Hardware and Software get married. First, they have to define their own love language; and second, they have to agree on how to work out problems that arise.

The love language between Hardware and Software is the core of their relationship. Without proper communication, the whole system breaks down and counselors are called in to mediate. Quite often a common heartbeat is involved (isn’t that romantic?) – one party periodically asks the other, “Are you there?” to which the other party must respond within a specific time frame, “Yes, dear, I’m here.” If either party ever ceases its half of the communication, the other begins to worry, files a missing persons report, and ultimately stops doing anything until its beloved is resuscitated.

Hardware has two major roles in communication: to report to Software what’s going on, and when it’s ready to receive new items on its honey-do list. It publishes a set of love notes called tags, or bits of information, which Software can read whenever it wants. Tags might represent a bar code on a bottle or tote that just passed through a scanner, or a flag that indicates the emergency stop button has been pushed, or an indicator that a particular transfer is enabled or disabled. Hardware also maintains a set of tags that tells Software when it’s ready to receive new instructions. When Hardware is done carrying out a prior instruction, it may set a tag value that signals it’s ready to receive the next.

Software has several roles in communication as well: to monitor Hardware’s tags so that it knows what state Hardware is in, and to give Hardware its instructions. Software may periodically scan a set of error tags that Hardware maintains in order to tattle report to Almighty User any conditions outside the norm. Software may also monitor the tags to see when Hardware is ready for a new instruction, and give it the necessary data for it to do its next task (for example, dispense 2 bottles from channel 15 as part of bottle group 3465).

How Hardware and Software communicate efficiently for success scenarios is one challenge of the pharmacy automation design process. Another is how to handle the outlier situations where, literally, anything can go wrong, either on the Hardware side or the Software side of the equation. Note: this is the part where we ask if anyone can present a reason why Hardware and Software should not be wed, let them speak now or forever hold their peace.

Hardware usually comes down to moving parts, but there’s more to it than that. Any moving part is capable of breaking or wearing out at some point. How does the PLC know that a moving part is malfunctioning? Usually it knows by looking at the input from a number of sensors that tell it what’s really going on. With the input from sensors, the PLC can set values for tags that Software will read and report to Almighty User on. So good Hardware design involves proper use of sensors, but sensors can go bad too. How can you tell when sensors go bad? Often, it’s a case of one sensor’s data not logically aligning with other sensors’ data, but not always. With so many moving parts and inputs to juggle, figuring out all of the potential failure scenarios becomes an exponential problem.

Meanwhile, Software has its own issues to deal with. With thousands of points of data to manage, what happens if bad data makes its way into the mix? What about cases where what Hardware is reporting doesn’t jive with what Database says? What if two different Softwares try to record different data in the same place at the same time? What if, in the process of reporting one exception, another exception crops up? What if the data that’s supposed to be there has disappeared because of a hard drive failure?

On top of Hardware and Software dealing with their own problems, they have to be able to communicate those problems effectively with each other. And when that happens, there’s always the possibility of network issues springing up to prevent that communication. For every one thing that can go right, there are a thousand things that could go wrong. Thus springs the need for solid and thorough design work, as well as thorough testing (see my previous article, Why Coders Should Not be Testers, from November 2016).

So the next time your pharmacy automation works as it should, and let’s hope it’s right now, be thankful for the marriage of Hardware and Software that’s built on a solid foundation of good communication. And what Developer hath wrought, let no one rend asunder.

Announcements | Blog | Software