TECHNOLOGY IN SYSTEMS
M2M: How Much Autonomy?
How Much Autonomy? Achieving Efficiency via M2M without Losing Control
Machine-to-Machine systems can assume a great deal of automation and autonomy. However, many applications and circumstances determine which data and decisions regarding that data should be left to the automated system and which need to be considered by humans.
CHRISTINE VAN DE GRAAF, LILEE SYSTEMS
Page 1 of 1
M2M can be machine-to-machine or mobile-to-mobile or machine-to-mobile among other alternative definitions. However, all definitions beg the question: Where does M2M autonomy end and the human decision making process take priority? Hollywood has given us at least two examples of how M2M autonomy can go horribly wrong: iRobot and Eagle Eye. In both cases, the machines were initially programmed to follow a base set of decision rules and guidelines. However, the connected machines were given the authority to act without a level of human guidance and began to make decisions that took their level of control far beyond what their creators had intended. And this doesn’t even touch on the intentions of hackers.
Are we doomed and heading down a path of giving too much autonomy to the M2M solutions being put into use today and to those yet to come? To counter the fear, uncertainty and doubt (FUD) that these “good idea gone bad” scenarios generate, we can look at how some modern day applications spanning the medical, finance and energy markets have been implemented. Application-specific checks and balances are being put into place to ensure that M2M solutions have an appropriate level of autonomy but that human gray matter has the final say.
If we say that the goal is to limit M2M autonomy, the problem becomes what systems do we want connected to one another and which do we keep separate? Developers also have to determine how they want to separate types of information communicated as well as the degree of separation. Is software partitioning sufficient? Does the separation require communication over a unified network but via separate data transport means (wired connectivity versus multiple types of managed wireless and radio connectivity)?Or do the networks have to be separated completely even though the user interface may be unified?
Machines function in absolutes. Machine language is ones and zeros. Some situations are that straightforward as, for example, in industrial automation and manufacturing where when one tool completes its given task the process moves on to the next step. If an error of stoppage is detected in the process, then the rest of M2M solutions in the environment react according to their absolute programming. Applications in medicine have gray areas and the same can be said of applications within energy and finance.
In the arena of modern medicine, there are many tools that healthcare providers and treatment researchers utilize. Heart rate monitors, medical image scanning machines, blood chemistry analysis systems and more collect massive amounts of essential information about patients. That information gets transferred now through M2M communications to their records as well as to those monitoring their status and treating them. The data creates a picture at a moment in time. Is that information sufficient for another machine to act on solo? Though one tool may get either a positive or negative result to a given test, is that sufficient data for an autonomous M2M communication and decision with another connected tool?
Through big data analysis, cross referencing up-to-the minute data with past patient data and other globally collected references, recommendations can be made, but there is a chance that a non-M2M measurable factor—such as treatment preferences with respect to taking extreme measures or administering comfort-care alone—could be overlooked. As more connected technology is utilized in this market area, there remains a separation between monitoring systems and treatment systems such that a trained person still is the decision-maker. Figure 1 gives an example of a connected health environment. This is consistent with the research side of the medical house in that there remains a high degree of human gray matter involved in determining success that would take a treatment process from lab trials to clinical trials and on to approved usage worldwide (see sidebar “The Phases of Clinical Trials for Drug Treatments”). Though the end-to-end M2M solutions involved serve as a thorough means of collecting data and communicating from the source to the applications that analyze it, teams of people remain involved ensuring that the medical mantra of doing what is best for the patient is kept in check even in light of what would maybe make sense for the business and legal sides of healthcare and treatment research.
In connected health, there is a degree of autonomy for M2M communication. M2M autonomy here is limited by programming and connection such that the non-machine measurable factors are not overlooked and patient safety is ensured.
This separation of tools and data is achieved through a combination of methods. The primary method of separation is through tool programming at the application level, which tells the systems what to do with collected data. Though all data is collected and becomes part of a patient or clinical trial subject’s electronic medical record, a portion of the data may be made available for lab tools to use for analysis but not sent directly to an automated drug injection pump. In addition to the programmable separation of data communication between M2M tools, there are some tools that cannot communicate with one another because they use separate means of communication. Some sensors may use Z-wave whereas others are set to use a different Wi-Fi technology.
In the case of the energy market, specifically Smart Grid communications, the means of establishing which M2M systems have autonomy and to what level takes another approach. The Smart Grid has been dubbed “electricity with a brain.” In Smart Grid technology, each device within the grid is associated with sensors that collect data—i.e., power meters, voltage sensors, fault detectors, etc. According to the National Institute of Standards and Technology (NIST), the smart grid is “a modernized grid that enables bidirectional flows of energy and uses two-way communication and control capabilities that will lead to an array of new functionalities and applications.” The two way communication encompasses both energy and information as illustrated in the NIST Smart Grid Framework image (Figure 2).
Overview of the Smart Grid framework (January 2010).
The Framework of the Smart Grid takes into consideration the need for secure communication flows as well as the energy flows. Each domain is interested in specific types of information, so the M2M communication and related adjustment capabilities are set up such that each gets the information it requires to make the adjustments that they have authority over. The standards are still developing for this newer submarket within the Energy space. According to NIST, these standards cover material, products, personnel qualifications, processes and services that are:
• applicable to their purpose;
• ensure compatibility and interoperability for subsystems that need to work together;
• preserve public health and safety;
• protect the environment; and
• optimize cost.
PAP01 is the standard that addresses the role of IP in the Smart Grid. This standard outlines the requirements of various applications of the Smart Grid and also identifies the core IP protocols (Figure 3).
Internet Protocols for the Smart Grid per PAP01 (June 2011).
Let’s take a specific example. Sensors at the Bulk generator domain (Figure 2) detect that there is shifting in the ground around the generator that could potentially impact the safe operation of the generator. This information is transmitted to the Operations and Transmissions domains. There, trained personnel can make appropriate decisions about whether or not to take the generator off line partially or completely or even at all. If the off-line decision is selected, then M2M comes into play again letting customers know how they will be affected before the off-line goes into effect. Alternatively, if there is a significant safety fault detected that could cause serious harm, then there is a parameter within the M2M communications of the overall Smart Grid system that does enable the M2M system to autonomously shut down the generator and trigger the next levels of action and information.
Overview of the Smart Grid framework (January 2010).
Finance applications such as automatic teller machines (ATMs) take yet another approach to setting boundaries for M2M autonomy. Through the user interface, the ATM machine itself delivers both marketing and promotional information to a customer as well as handling fund transactions. These two types of uses differ in sensitivity and have to be handled through completely separate networks (Figure 4). Since the information that they are handling is very sensitive, the M2M autonomy in such use cases is minimized.
M2M financial transactions are fully managed over a separate network infrastructure than non-financial banking applications.
Other mobile M2M devices play into finance as well. A user may choose to do much banking via their mobile smart device. That results in a significant amount of user data that could suggest a preference. However, it doesn’t absolutely mean that the user wants to go away from brick and mortar banking. Similarly, if a user makes repeated identical transactions, i.e., withdrawal of $20 every Friday, this too is data captured by M2M solutions. Neither means that the user wants to be switched to eBanking or to have an automatic withdrawal set up. The limitation to M2M autonomy in finance ensures that only the activities the user authorizes with respect to their accounts are enacted.
Yes, the world is moving to increased connectivity and we appreciate that we can automate some aspects of life. However, life is not black and white. Not all data leads to one specific action. We humans aren’t ready to hand over all the decision making to the M2M intelligent systems. The methods discussed here are the tip of the iceberg with respect to how the line is being drawn for M2M autonomy and ensuring that human gray matter has the final say in given situations.
SIDEBAR: The Phases of Clinical Trials for Drug Treatments
Before a treatment can be approved for mass usage, it has to undergo extensive study and an intense independent review process that may take a number of years. All of these checks and balances are designed for the well-being of patients.
Phase 0 – Pharmacodynamics and Pharmacokinetics: This is the first point at which a drug treatment is tested in a sub therapeutic dosage on a very small number of subjects (no more than 15). This gives the researchers preliminary data about what the drug does to the body as well as what the body does to the drug.
Phase 1 – Screening for Safety: In this phase, researchers work with a larger subject group (20-80). This is when researchers are trying to determine the safe dosage levels and identify side effects.
Phase 2 – Establishing the Test Protocol: When the trial gets to this stage, researchers are continuing to evaluate the safety of the drug but with yet a larger subject set (up to 300). They also are evaluating the effectiveness of the drug treatment.
Phase 3 – Final Testing: Up to 3000 subjects take part in this stage of testing, allowing researchers to gather data that confirms treatment effectiveness, monitors side effects, compares this treatment to other treatment alternatives, and collects further safety information.
Phase 4 – Post Approval Studies: Even once approved, research does not cease. There is ongoing research to assess treatment risks, benefits and optimal use.
There are serious adverse events that, if they happen during any one of the phases of clinical research, may result in the stoppage of the trial. These include death or life-threatening reactions, prolonged hospitalization, significant disability and congenital anomaly. Human research is highly regulated and further details are available in the Code of Federal Regulations (CFR) and the E6 Good Clinical Practice (GCP) Consolidated Guidelines.
Santa Clara, CA