Author Archives: admin

Developing counter-drone technologies not so easy

1 Reply

It’s not easy countering drones.

As fast as the drone industry is growing with hobbyist and commercial drone counts in the low millions by 2021, some anticipate that the counter-drone industry will be even larger with a combined annual growth rate of almost 26% between 2017 and 2021.  Increasing the challenge, because of the multitude of factors involved in drone deployments and the many places of interest where drones can be deployed, whether individually or en masse, there are a surprisingly large number of scenarios to consider when developing and deploying counter-drone technologies and that in turn makes development and deployment of counter-drone technology particularly difficult.

There are obvious concerns amongst commercial, private, and government entities around risk stemming from drone use (to include property loss, privacy, injury, and potentially death) — such as drones over flying nuclear plants in France, drones snooping in the Olympics in Rio, drones with cameras outside 26th floor high rise apartments in Seattle, and many others. The challenge is that there are so many factors and so many interdependencies between those factors, that it can be hard to establish a shared conceptual framework around counter-drone approaches to even have a discussion about the concerns.

Already, many different approaches to counter-drone strategies

The broad and varied approaches of counter-drone technologies already on the market speak to the diversity of potential drone deployments and the areas in which they will operate – and which ostensibly there is a desire to be countered. For example, DroneShield’s DroneGun uses a rifle-like radio frequency jammer. Skywall uses a shoulder-fired drone-capturing net. The US Air Force is trying out net-filled shotgun shells by SkyNet and Malou Tech offers drone-nets-drone technology. And the US Navy and Marine Corps bring it on home with laser, aka directed energy, anti-drone approaches. The approaches are wide-ranging and I think we’ll continue to see even more evolution and many more companies in the space.

One approach for considering counter-drone systems

An approach discussed here splits out variables/attributes in drone deployments and operation from the variables/attributes of the operating area and what it contains into two separate sets of factors. This provides a broad base for conceptualizing counter-drone considerations. These two sets of factors are:

1. drone deployment attributes and
2. drone operating area attributes

In turn, each set of factors also has its own multiplicity of factors and interdependencies between them.

counter-drone sets of factors071017

many factors to consider in counter-drone systems development

 

Drone deployment attributes

When considering how to counter drones, there are many factors that contribute to any particular drone deployment. A few of them are:

  • Mass – How much does the drone weigh?
  • Altitude – Is there a characteristic altitude of the deployment?
    • < 50 feet?
    • 50 – 200 feet?
    • above 200 feet?
    • varies?
  • Potential Energy (PE)
    • derives from mass & altitude
  • Velocity
    • Is there a characteristic speed of the drone(s)
      • 5 mph?
      • 5 – 20 mph?
      • > 20 mph?
      • Varies?
  • Kinetic Energy (KE)
    • derives from velocity and mass of drone
    • rotor rotation also contributes to KE
  • Volume – What is the size of the drone?
    • cross-section?
    • diameter across opposing rotor tips?
  • Cardinality
    • Is it just one drone?
    • 2 – 25 drones?
    • 25 or more drones?
  • Behavior >1 drone
    • is the behavior coordinated?
    • are they operating independently?
    • sporadic?
  • Intent – Is the operator intent:
    • malicious?
    • benign?
    • negligent?
    • operator-impaired?
  • What is the payload of the drone?
    • nothing?
    • camera?
    • explosive
    • radiological?/chemical?
    • combination?

Effects of factor interdependencies (aka Potential Energy can become Kinetic Energy)

As discussed, these factors can have substantial interdependencies between them as well. One of the interdependencies that is the most basic and seems to be often forgotten in conversation is that any drone with any altitude has Potential Energy. Regardless of motors, batteries, wind, payload, etc — just the fact that a mass (drone) has been raised to an altitude, it now has Potential Energy. The larger the mass and the higher the altitude, the more Potential Energy is converted to downward directed Kinetic Energy if a drone stops flying – for whatever reason. This may be important to anyone in the path of the dead drone’s earth-seeking trajectory.

city2

Drone operating area attributes

The other part of the equation is what is the drone’s operating area? What are those things on the ground (or in the air) that have value? This could be the value that one puts on their individual privacy, to the value a corporation puts on a production facility, the value a city puts on a power substation, or the value of 50 people watching a little league game or 50,000 people watching an NFL game. Some operating area attributes/variables include:

stadium2

 

  • Does/do the drone(s) fly over a population?
    • Population size – 10’s, 100’s, 1000’s, more?
    • Density
      • rural
      • city
      • high density congregation (eg professional sports game, parade, concert, ..)
      • does the population density change, eg high when ball games & low when not
    • Does/do drone(s) fly over/near critical infrastructure?
      • power
      • water –  dams, reservoirs, …
      • gas
      • sewer
      • nuclear
    • Does/do drone(s) fly over/near schools, churches, hospitals …
    • Does/do drone(s) fly in area of critical radio spectrum?
      • broadcast
      • police, fire
      • aviation, marine
      • military

    ci2

    Counter-drone Combinatorics

    So let’s take a combination and create a constraint domain to illustrate the point.  Where there is a broad range or spectrum of possibilities for a particular attribute, I break them down into three arbitrarily chosen sub-ranges. This will allow us to make the numbers smaller and a little more manageable and yet still see how the number of possibilities to consider can become quite large. You can, of course, break them down into whatever sub-ranges you would like and into as many sub-ranges as you would like.

    the number of scenarios can scale quickly

    the number of scenarios can scale quickly

    Some counter-drone systems will naturally address multiple scenarios. However, to be effective and competitive in a rapidly growing market, the counter-drone systems developer has many flight profiles and many operating area profiles to consider.

    Another factor in counter-drone technology development is the legal aspect. Examples include laws regarding national aviation system navigational system protection, individual state law, and civil lawsuits. This will likely be a substantially evolving landscape as drone technologies evolve and damaging events occur with real loss.

    Dynamic landscape

    When considering the factors involved in developing or evaluating counter-drone technologies, one approach that can be helpful is to think about both the characteristics of the drone (or drones) potential flight as well as the area in which the flight will occur and what’s valuable in that space.

    With rapidly evolving and distribution of drone technologies, rapidly evolving counter-drone technological approaches, increased public awareness, and changes in local, state, and federal laws, I think investment, development, and deployment of counter-drone technology will continue to be a very dynamic realm.

In IoT ecosystem evolution, constraints = opportunities for IoT innovators

Leave a reply

What are our opportunities for guiding the rapidly evolving IoT ecosystem? The Internet of Things, with its explosive growth, unprecedented variety of device & system types, lack of broadly shared language and conceptual frameworks to discuss and plan, lack of precedence for implementation, and the organizationally complex consumer systems — i.e. cities and institutions — required to implement and manage these IoT systems — all make for a challenging space. It can be difficult to even know where to start. One way to add structure and framework to the conversation is to introduce some constraints — and good news! There are constraints already there! They’re just not broadly seen or talked about yet.

What does a successful IoT system implementation look like ?

A natural source for constraints is from those things that define a successful IoT System implementation in an institution or city. I use two primary components to define IoT System implementation success:

  1. Return on Investment (ROI)
  2. Cyber risk profile

Regarding the first — ROI, does the system do what we thought it would do at the costs/investment that we thought would be incurred? As discussed in a recent post on IoT System costing, determining costs of IoT Systems implementation is different from traditional enterprise systems. Most institutions and cities have little experience at it and are generally not very good at it. Further, other subtleties such as expectations of the data created from deployed IoT systems across a spectrum of populations, demographics, & constituencies directly impact perceptions of system (and investment) success.

Regarding the second — cyber risk profile, did the IoT System implementation make things worse for the institution or city? Cyber risk profile degradation can come from poorly configured devices/endpoints, insufficient management resources (skill, capacity) for endpoints and data aggregators/controllers, inadequate vendor management, and others.

Constraints drive opportunities in the IoT ecosystem

These same two analysis requirements of a city’s or institution’s success, aka constraints, can also be used by innovators and providers of IoT systems. Knowledge of these constraints by IoT systems providers, these requirements for city/institution implementation success, creates opportunity for the IoT systems innovator and provider by identifying where they can help address organizational complexities in the course of pursuing ROI and cyber risk posture/profile objectives.

IoT systems are different

As discussed in other articles and posts, IoT Systems are different. The process of selecting, procuring, implementing, & managing IoT systems is different from doing the same for traditional enterprise systems such as email, calendaring, resource and customer management, etc. At least six aspects of IoT Systems contribute to this difference:

  1. High number and growth rate of IoT devices
  2. High degree of variability of device types & variability of multiple hardware/software components within a device
  3. Lack of language and frameworks to discuss IoT opportunities, risks
  4. IoT Systems span multiple organizations within an institution or city
  5. IoT endpoint/devices tend to be out of sight out of mind
  6. Lack of precedent for successfully implementing these systems, few examples, few patterns to follow

Of these differences, #4 – the organizational spanning aspect of IoT Systems — presents a subtle but substantial challenge. Deploying IoT Systems in a city or institution is not like deploying an enterprise application in a data center or SaaS in the cloud and then providing for end-user training and support. This, of course, does not mean that deploying large enterprise systems is easy by any stretch, but rather that there are more and different organizations required in the technical, operational, and management aspects of the system.  Because of this, new levels of inter-organizational cooperation and collaboration are sought. And, as we all have experienced, collaboration and cooperation is frequently touted but successful collaboration and cooperation is often not achieved — “the discrepancy between the promise of collaboration and the reality of persistent failure” (Koschmann).

Cities and institutions are complex multi-component organizations that offer a complex substrate for IoT System implementation. These complex IoT product and service consuming organizations are not blank slate, clean whiteboard, or powerpoint deck solution organizations. There is little homogeneity here.

IoT Systems innovators and providers that recognize these constraints brought on by these complex consumer systems, that seek to learn the institutional organizational challenges in detail, and get in the dirt at the outset with the city or institution will ultimately be IoT Systems ecosystem drivers.

“I built it in my garage, it works there, it’ll be awesome in your city!”

Because of the seemingly unbounded potential of IoT Systems solutions, there’s also room for undifferentiated, poorly provisioned, and poorly serviced garbage in this space.

Because of the newness of IoT Systems, often there are many technologies and many vendors without particularly long track records. There are some big names in the game of course — Cisco, Microsoft, Intel, Siemens for example. But there are many providers in that long tail, both proven and unproven, and some of them will offer great innovation and value. Some of them will not. The challenge for institutions and cities is to work to separate the wheat from the chaff as they select, procure, implement, and manage IoT Systems.

Going by name brand alone is not sufficient because there will be many new innovators and providers that do indeed offer promising and solid solutions that give a reasonable likelihood of ROI and an approach that does not degrade the existing cyber risk profile of the institution. Further, sometimes large companies can be problematic because they are used to throwing their weight around, possibly invested heavily in particular approaches, and may not be open to new or alternative approaches. This may or may not be with whom a city or institution wants to work.

Eyes off the bling for a moment

So how can a city or institution begin to separate the wheat from the chaff in choosing IoT systems? An initial step can be to take one’s eyes off of the ‘bling’ for a moment. The bling is all of the feature sets and bells and whistles that most think of when they think of IoT systems. So, a three step process would be:

  1. Take eyes off of the bling (feature sets, bells & whistles) for a moment
  2. Review implementation challenges internal to the institution
    • organizational spanning complexity
    • calculating IoT system support costs across all organizations
    • analyzing internally available skill sets and capacity
    • consider what criteria different demographics will use to assess success or failure
    • seek input in estimating cyber risk to which an  institution or city is already exposed to provide an estimated baseline
  3. Seek and prioritize IoT Systems innovators/providers that help address some of these internal organizational challenges and shortcomings

insideoutoutsidein

Cities and institutions look inside out — Some of their internal challenges include:

  • organizational complexity (spanning)
  • IoT system support staffing capacity
  • appropriate skill sets
  • IoT system support tools availability & experience
  • what ROI will a particular provider’s IoT system bring?
  • will implementing this IoT system make my cyber risk picture worse? how do I know?

IoT innovators & providers can look outside in —  and use these constraints to create market differentiators for their organizations, such as:

  • can I help city/institution address internal challenges?
  • can I provide tools to help them manage their system?
  • can I help them reach the ROI they were expecting?
  • can I help them mitigate their cyber risk from this implementation?

Not just one IoT System

We’ve been talking about just one prototypical IoT System for an institution or city. In practice, institutions and cities will have many IoT Systems. Many of these  IoT Systems will:

  • use shared technical resources of the city or institution, eg network and supporting systems
  • have interdependency with other systems
    • at device level
    • at data level
    • to include co-existing with legacy systems & new systems
  • dip into the same limited pool of skill sets and capacity for systems support

This further deepens the IoT Systems management challenge within the city or institution. Implementation challenges for these complex city and institutional consumers will only continue to grow. They won’t diminish.

IoT Systems innovators and providers that recognize and speak to this additional level of complexity — this ecosystem with multiple providers and vendors within an institution —  and provide options, services, and support to help cities and institutions manage this complexity will set themselves apart from the competition and develop longer lasting relationships.

In this seemingly open-ended space of IoT systems possibilities, identifying and developing solutions for organic complex consumer constraints and challenges can be a differentiator for IoT product innovators and service providers.

FAA drone activity timeline

Leave a reply

The FAA has found itself in a bold new role over the past few years regarding drone, aka Unmanned Aircraft System (UAS) policy, registration services, guidance, detection, establishment of permanent and temporary no drone zones, studies on drone/human collision risk and impact, and related areas. We can expect that this will continue to be a very active space over the next several years.

A timeline of some FAA drone activity since early 2015 is depicted below. The graph shows the total number of FAA News/Updates and Press Releases for that month. I used the FAA’s website news search engine to get these numbers. (I used the dates from search engine as the basis even though the actual event date might have differed by a few days in a couple of cases.) Some representative links to FAA News/Updates and Press Releases follow the graphic.

FAAdronenewsprtimeline2

Super Bowl XLIX
Super Bowl 50
Super Bowl LI

Other No Drone Zone announcements —

DC kicks off No Drone Zone
Papal visit No Drone Zone press release

Airport drone detection system updates —

Denver International Airport & FAA partner on drone safety
Testing FBI drone detection systems @ JFK
Evaluating drone detection systems in Denver area
Testing drone detection system @ DFW

Other notable updates —

Drone registration site launched
San Francisco 49ers launch drone safety effort
Registration requirements go into effect
FAA responds to Court of Appeals reversal of registration requirements

 

Clearly, drone policy development and enforcement, drone detection and management systems, other drone-related tech, and messaging the same to the public is likely to a substantial growth area and effort for the FAA over (at least) the next several years.

Costing IoT Systems in cities & institutions

Leave a reply

Determining the total cost of ownership, operation, and stewardship of IoT Systems for an institution or city has a number of considerations. Some of these considerations are shared with traditional enterprise systems and some are unique to IoT Systems. Lack of realization and acknowledgement of these costs can lead to disappointing and costly IoT Systems outcomes. These disappointing outcomes manifest themselves in the lost ROI of an IoT investment as well as negative impacts to the cyber-risk profile to an institution.

Listing from least complex/nuanced to more complex/nuanced …

  1. Costs to host servers, databases, & redundancy — whether under desks (hopefully not), in local data centers, or in the cloud
  2. Costs to support large numbers of geographically distributed ‘Things’ & devices (the T in IoT) & the different institutional organizations that may be involved (some of which may not see or realize the potential benefit to the institution but may bear at least some of its support costs)
  3. Costs stemming from the natural friction, sometimes small & sometimes large, between multiple historically disparate organizations within an institution as they attempt to coordinate, collaborate, and address problems of understanding to support the system

1. The more familiar part — application server, database server, & redundancy costing

This costing is more closely aligned with traditional enterprise application costing than other IoT systems costs. Application licensing and support agreements are a part of this aspect. Important additional costs to include, though, are: what are the costs of hosting those applications and databases? And what are the costs of supporting that hosting (e.g. who manages the relationships, the tickets, the problems, etc).

The applications servers or virtual machines (VM’s), database servers/VM’s, and redundancy servers/VM’s can be hosted in a local data center, shared data center, the cloud, or similar. Hosting or otherwise servicing these applications and supporting databases have their own costs. In addition to fees for the hosting, there’s also some cost to managing the vendor relationship and agreement/contract.

2. A guy, a truck, and a ladder – a less obvious part of IoT System costing

 

this is not cheap

this is not cheap

Imagine an institution or city that implements 500 smart street lights that provide lighting, sense movement, maybe samples air quality, and possibly monitors and reports street or underground vibration. There will be some failure rate amongst the components in any single device/endpoint and some failure rate across the total number of installed devices/sensors – the T’s in IoT.

In this hypothetical scenario, troubleshooting and/or repair means:

  • deploying 1 or more skilled tradespeople
    • 1 or more for the work & possibly another as a safety observer
  • rolling a truck or trucks
    • with associated vehicle/fleet/fuel costs
  • spending 1-2 hours just to get to the point of troubleshooting/repair
  • 2 – 4 hours troubleshooting/repair
  • 1-2 hours wrap up and return

For this hypothetical example, let’s say the skilled tradespeople involved make $60/hour and their benefit load (expense to institution or city) is 25% for a total $75/hour expense. So, disregarding fleet and related costs, one estimate might be:

(2 hrs prep + 4 hrs on site troubleshooting/repair + 2 hrs recovery) x 2 tradespeople x $75/hr = $1200 per support event

Continuing on the thread, let’s say there’s a 10% / year failure rate (or required hardware/software update rate) of at least some component on a single device or Thing (T in IoT). That would be:

500 devices x 10% repair or troubleshoot rate/year x $1200/event = $60,000 / year

That dollar figure starts to become non-trivial. And that’s just one IoT System. Cities and institutions will have many, a portfolio, of well-managed or less-well-managed IoT Systems. Another hypothetical example is in the example  below —

IoTSysCostingExample050917

multiple costs involved

3. The insidious part — loss from organizational friction

The least apparent and possibly most costly aspect is the loss that occurs from the coordination and collaboration required between organizations and the oversight needed across all of them for a successful implementation. In the idealized scenario of institutional capacity, there is a homogeneous set of resources that include components such as available staffing levels (FTE), requisite skill sets (technical, operational, and interpersonal), support funding, political/institutional will to support the implementation and operation of the IoT System, vendor relationships, and other.

idealizedcapacity

idealized view of IoT System management capacity

In practice, however, this institutional capacity is comprised of many different organizations and the interrelationships between them.  While collaboration and inter-organizational cooperation is typically universally lauded, we all know from personal and professional experience that often collaboration between institutional organizations does not in fact work so well. Research has also been done on this phenomena where, “the discrepancy between the promise of collaboration and the reality of persistent failure” is studied (Koschmann).

Wherever two or more organizations interact with each other, some sort of friction or system loss is present. Metaphorically similar to the 2nd law of thermodynamics, not all of the time, energy, resources put into ostensible institutional IoT System management capacity will be used, or can be used, to do the expected work. In the organizational friction example, losses can come from a multitude of sources where the number of friction sources and the intensity of each can vary from organizational relationship to organizational relationship. Examples of this sort of friction/system loss and resultant loss in expected institutional capacity include:

real capacity stems from multiple organizations with multiple relationships and the friction between

real capacity stems from multiple organizations with multiple relationships and the friction between

The insidious part is that while the friction between any two organizations, may be small and possibly not obvious, these small instances of organizational friction aggregate across the whole institutional and IoT System implementation effort. Further, not all relationships are one-to-one. There are often many relationships where many organizations are involved. Likening to Newton’s Three Body Problem, adding a third planet, billiard ball, or organization can significantly increase the complexity of analysis, prediction/forecasting, and the ability to get work done.

capacityloss

 

Costing differently

In practice, capturing all of these costs can be challenging. #1 — application and database licensing and hosting costs is relatively the most straightforward and for which we generally have the most experience, but that doesn’t mean it’s effortless. We have less experience with #2 for IoT Systems — the guy, truck, & ladder costs — but that support cost can be estimated and the failure rates of devices and device components can be estimated. Costing #3 — aggregated inter-organizational friction is, by far, the most difficult and possibly the most impactful — in part because of its magnitude and in part because of the uncertainty it introduces.

The import thing, I believe, is to acknowledge all of these components, compute and estimate what we can, and work to allow for and hopefully prepare for the unique uncertainty that selecting, procuring, implementing, and managing IoT Systems brings. If we do this work, we have our best chance of reaching anticipated ROI and not degrading (possibly even enhancing) the risk profiles of our cities and institutions.

 

 

Can we manage what we own? — IoT in smart cities & institutions

Leave a reply

The rate of growth of IoT devices and systems is rapidly outpacing the ability of an institution or city to manage those same devices and systems. The tools, capacities, and skill sets in institutions and cities that are currently in place were built and staffed for different information systems and technologies — centralized mail servers, file sharing, business applications, network infrastructure support, and similar. Some of these systems still exist within the enterprise and still need robust, effective support while others have moved to the cloud. The important consideration is to not assume that toolsets developed for traditional enterprise implementations are appropriate or sufficient for IoT Systems implementations.

What's manageable- 032217

things are increasing faster than the ability to manage those things

Working from the outside in

Starting with the outer ring, the number of ‘things’ — the T in IoT — is rapidly growing within institutions and cities. From my perspective, an IoT ‘thing’ is a device that computes in some way, is networked, and interacts with its local environment in some way. Further, these systems may be acquired via non-traditional methods. For example, a city’s transportation department may seek and acquire a sensor, data aggregation, and analysis system for predictive maintenance for a particular roadway. This system might have been selected, procured, implemented, and subsequently managed independently of the organization’s traditional central IT organization & processes. Complex and high data producing systems are entering the institution/city from a variety of sources and with little formal vetting or analysis.

Can we even count them?

Because of the rapid growth of IoT devices and systems in concert with alternative entry points into the city/institution, even counting (enumerating)  — these devices — which can compute with growing ability and are networked — is increasingly difficult. This lack of countability in itself is not so bad, it’s just a fact of life – the trouble comes when we base our management systems on the assumption that we can count, inventory, much less manage all of our devices.

What do we know about the devices?

Do we have documentation and clarity of support for the tens, hundreds, thousands (or more) of devices. What do they do? How are they configured? Have we set a standard for configuration? How do we know that that standard is being met? What services do we think should be running on the devices? Are those services indeed running on them? Are there more services than those required running? Are there processes for sampling and auditing those device services over the next 12 – 36 months?  Or did we install them, or have them installed, and simply move onto the next thing?

We can borrow from the construction industry and ask for as-built documentation. What actually got installed? What are the documents that we have to work with to support this system? Drawings? IP addresses? Configuration documents for logins, passwords, open ports/services?

What is manageable?

If we are in the fortunate position to be able to actually count these computing/networked/sensing devices with reasonable accuracy and we know some (enough) things about the devices, then the next question is — do we have the resources — staffing, time, skill sets, opportunity cost, etc — to actually support the devices? Suddenly in smart cities, smart institutions, smart campuses, we’re installing things, endpoints, in the field that may require regular updating (yearly, monthly, …) — and this occurs between the customer network with its protocols/processes and the vendor system that is proposed. Not all (possibly substantial) device updating can be accomplished effectively remotely.

Another challenge is that often the organizations that are charged with staffing, installing, and supporting these deployed IoT devices, such as smart energy meters or environmental monitoring systems, are more accustomed to supporting machines that last for years or decades. Such facilities management organizations have naturally built their planning, repair, and preventative maintenance cycles around longer periods. For example, a centrifugal fan in a building might have a projected lifespan of approximately 25 years, soft start electric motors 25 years, and variable air volume (VAV) boxes with expectancies of 25 years.

Similarly, central IT organizations generally are not accustomed to running out into the field with trucks and ladders to support 100’s, 1000’s, or more of computing, networked devices in a city or institution. So the question of who’s going to do the actual support work in the field is not clear in terms of capacity, skill sets, and costs.

device count vs mgmt ability 032217-3

Actually managing the things

So, if we have all of the above — and that subset gets smaller and smaller — have the decisions been made and priorities established to actually manage the devices? That is, to prioritize, risk manage, and develop process to manage the devices in practice? There’s a good chance that manageable things won’t actually be managed due to lack of knowledge of owned things, competing priorities, and other.

On not managing the things

It is my opinion that we will not be able to manage all of the ‘things’ in the manner that we have historically managed networked, computing things. While that’s a change, that’s not all bad either. However we do have to realize, acknowledge, and adjust for the fact that we’re not managing all of these things like we thought we could. Thinking we’re managing something we’re not is the biggest risk.

We’re moving into a world of potentially greater benefit to the populace via technology and information systems. However, we will have to do the hard work of being thoughtful about it across multiple populations and realize that we’re bringing in new risks with some known — and unknown — consequences.

Creating IoT Systems Manageability – A Risk-Managed Set of Networked Things

1 Reply

To achieve IoT Systems ROI and to ensure non-degradation of an institution’s existing cyber-risk profile, IoT Systems must be manageable. In turn, in order to build IoT Systems manageability, institutions will need to manage their IoT Systems risk with non- traditional approaches that includes assigning IoT endpoints (the ‘things’ in IoT) to risk categories that can be independent of the underlying technologies and vendors.

IoT Systems are increasingly complex to implement, manage, and to establish system ownership in institutions, whether cities, Higher Education institutions, or corporate campuses. In turn, an institution’s IoT Systems Portfolio – a systems of systems – rapidly deepens the complexity. We will need to tackle the problems and challenges in new ways and with new organizational concepts if we are to have an opportunity for well-managed and reasonably risk-mitigated systems. This includes thoughtful inter-organizational planning, partnerships, and development of a more common language between central IT, distributed operational organizations and departments, and vendors. Further, this will be required to establish system ownership and management plans between organizations such as facilities organizations, central IT, research groups, vendors, and others. One step toward this objective is identifying things to be managed independently of the technologies and vendors implementing them — a Risk-Managed Set of Networked Things.

Central IT won’t own all of the IoT Systems

Traditional enterprise network and system management tools, staffing models, and even language are ill-equipped to address this rapidly changing technology. Historically, network and system management tools have all been within the purview of central IT. Central IT will not be able to keep up with the accelerating growth of IoT Systems across an institution. Just like central IT organizations cannot manage every user/academic/business application on their networks (or even many of them), central IT will not be able to support all of the IoT Systems either. Business owners — operational (academic in the Higher Ed case) and administrative — will have to share that load. That’s better for them too — they are closer to the problem and have a truer understanding of desired outcomes from the system. Implementing this coordination across two or more organizations in the institution is new work though. There are not great precedents for this. Institutions, particularly Higher Education institutions, are known for their bureaucracies within bureaucracies, entrenched ways, and “cylinders of excellence..” (aka silos) .

system of system of systems ...

system of system of systems …

In a similar fashion facilities management organizations have substantial skill sets in building in and integrating equipment into built environments whether they are buildings or spaces. However, facilities management organizations don’t have network design, implementation, network management, and traditional server management skill sets. Finally, while operational departments, whether acting independently or in collective partnerships with other operational departments, know what they want systems to do and comment on performance, they do not have the required skill sets that facilities management and central IT groups bring to the table.

This organizational-spanning nature of IoT Systems in institutions make establishing ownership and a post-implementation management plan particularly challenging.

Designing for & building IoT System manageability

The growth in institutional system count, system complexity, and system interdependency makes for rapidly evolving systems management and owner environments for Higher Ed institutions. We have to take definitive steps to make things more manageable. That is, we have to design for system manageability. Applying historical and traditional tools and organizational approaches to this rapidly changing environment will no longer be sufficient.

A core component of any framework to facilitate manageability is a language, or at least shared concepts, that support it. In turn, a substantial objective of that shared language development (shared, for example, between central IT, facilities, and operational users) is to develop structures that make the systems more manageable. This sounds obvious, but in our complex environments and with our dwindling availability of time and cognitive bandwidth, it is easy to lose sight of this objective.

Agreeing on what is being managed

Before different organizations within an institution can establish those manageability- facilitating-structures and figure out how to partner, establish ownership, and mitigate risk to institutional systems, they have to be able to mutually identify and agree upon what is being managed. What is the set of things — devices, systems, spaces, buildings, infrastructure, etc — that we care about managing, from both operational and risk mitigation standpoints?

In days of relatively simpler systems, sets of networked things/devices to be managed were often defined by the network itself and/or systems on the network and/or the particular brand of technology supporting the network. Further, these networked things/devices were typically run by central IT organizations and these organizations were comfortable with using locally understood network terminology and concepts to define that set of things. Examples include — devices/things on a particular subnet or set of subnets, devices/things behind a particular firewall, on a particular VLAN or VRF, etc.

These examples above don’t mean much to potential system owners that are business organizations and/or academic organizations. The terms used are way too abstract, jargon-y, and/or colloquial. The cross-organizational planning and coordination needed for IoT Systems implementations and subsequent management cannot occur if participating groups can’t mutually identify what is to be managed.

Also problematic in trying to apply these old approaches of identifying things and systems to be owned, operationally managed, and risk-managed is that it is easy to slip into the high-granularity/high-entropy of technical details when the initial conversation is simply identifying and agreeing upon what is to be managed. Because these new and rapidly evolving technologies are increasingly complex, requiring increasingly deep technical skill sets, conversations in technical detail can be challenging even for technical professionals and effectively useless for potential academic and business partners and systems owners.

Finally, sets of things/devices to be managed might involve multiple technologies — eg maybe partially wired, partially wireless/near-field, on a VRF, behind a firewall, etc. So using a technology as a defining mechanism is further unhelpful. While a particular technology or network might happen to align well with a business need for defining a group of assets to be managed, we don’t want to start with that assumption.

IoT System Manageability Groups – A Risk-Managed Set of Networked Things

To address these shortcomings, we can consider a Risk-Managed Set of Networked Things (RMSONT). In this approach, we work to establish sets of networked things based on what best enhances manageability of the system. This is independent of underlying implementing technologies, particular vendors, and existing organizational charts.

What constitutes IoT System manageability?

A managed IoT System will have at least these attributes:

  • the IoT System was selected methodically and with purpose
  • the IoT System is named & known
    • the system has a common name that is known, shared, & published to participating parties (eg central IT, facilities management, operational departments, etc)
  • devices/things of the IoT System are enumerable
  • that is, via network process the device can be known and named
  • IoT System owners identified
  • IoT System component owners identified
  • satisfactory system performance is defined
  • system performance is measured
  • system performance is reviewed by business owners and systems support providers
  • estimates of total costs are established and shared — includes IT and Operational Technology (OT) costs
  • other

What are the qualities/attributes of a thing/device?

Things/devices in IoT Systems have at least these qualities or attributes —

  • a location
  • a function (what is it supposed to do)
  • an IP address; a MAC address
  • a power requirement
  • an associated data aggregator or controller
  • supports a user, users, or population (department, organization, constituency, etc)
  • rate of failure (estimated or known)
  • other

Creating a Risk-Managed Set of Networked Things

The #1 goal is to build and enhance IoT Systems manageability. A risk-managed set of networked things is established to create a manageable group. This could be a group managed by the business consumer or an institutional service organization such as facilities management or central IT — whatever best facilitates system ownership and management.

Multiple sets of risk-managed things can be created to facilitate overall system manageability. One example of a set of risk-managed sets might be:

  • law enforcement/security office owns and manages a set of networked video cameras (possibly with support from central IT, facilities management, local IT, vendor, etc)
  • in an academic setting, a researcher that uses a specialized HVAC IoT System with sensors, actuators, and data aggregation to provide tight environmental control of their research environment might be a logical choice to own that system
  • a metering system might best be managed by the institution’s energy management office
  • a building manager might have a risk-managed set of networked things local to their particular building, but of different types of things— surveillance cameras, energy management system, etc

In general, getting those most familiar with the IoT System’s performance expectations and actual performance into a system management role is probably a good idea.

As we talk about sets of things, and particular kinds of sets of things, we can borrow lightly from the mathematical idea of groups.

As I understand it, mathematical groups are:

  1. Sets of things
  2. These things abide by or participate in some set of rules
mathematicalgroup

A selected set of things abiding by a certain set of conditions & operations …

Similarly, a Risk-Managed Set of Networked Things, can be:

1. A set of networked and computing things/devices (that interact with the environment)

2. These things/devices participate in or are governed by some sort of network management processes and human management processes — eg automated network device enumeration/inventory, device health/responsiveness, etc

iotsystemsgroupimage

RMSONT – A Risk-Managed Set of Networked Things

 

You gotta keep ‘em separated (or not)

To borrow from Offspring’s social commentary (and popular song) on gang membership, colors, and violence in Come Out and Play, the theme of IoT Systems and network segmentation seems to be, “you gotta keep ‘em separated.” The problem is that that is not as easy as it seems.

offspringlive

tie your own rope, tie your own rope, tie your own rope (hey!)

Network segmentation has been all the rage as an answer to IoT Security and risk mitigation. However, as we’ve seen, network segmentation alone is not sufficient. Risk-managed sets of things need to be thoughtfully chosen, the rules and operations supporting that set of things needs to be thorough, and systems owners thoughtfully coupled with systems in order to achieve manageability.

We can manage IoT Systems within our institutions. And we can manage portfolios of IoT Systems within our institutions. However, we need to acknowledge that these are different kinds of systems and that our existing traditional IT systems operational and risk management approaches are likely insufficient. From that point we can sculpt and evolve new management approaches that facilitate successful, well-managed IoT Systems portfolios.

Understanding data expectations is essential to IoT Systems & Smart City/Campus success

Leave a reply

One of the subtle but powerful factors affecting IoT Systems implementation and management success in complex organizations such as a smart cities and smart campuses is the change required in becoming a data centric organization. In most cases, this is not a small transition. The evolutions of these cities and institutions has been from a place of relatively limited data – and certainly not ubiquitous data – available across multiple contexts. When an organization begins to shift, or seeks to shift, to an organization where data production, acquisition, consumption/analysis, and management are core to its operation and to its perception of self, subtle but powerful cultural and organizational change is required.

Data generation and/or acquisition is a major component in almost all IoT Systems that may be deployed in support of smart cities or smart campuses. It’s where the money is, so to speak. The challenge is that the expectations of data from the many constituencies and consumers can vary in significant ways and these variances in expectation, in turn, influence perceptions of IoT System, and hence smart city system, success. Further, early IoT System implementations that are viewed as failures in support of a smart city or smart campus not only mean lost investment on those particular systems, but also that these failures will (understandably) make constituents wary of funding or deploying subsequent systems.

Reflecting on and planning for what our expectations of data are in our different constituencies and contexts can go a long way to helping us identify what successful IoT Systems implementations and smart city deployments might look like.

A framework for an organization’s expectations of data

University of Washington researchers Brittany Fiore-Gartland and Gina Neff have proposed a framework for considering those data expectations in the context of health and wellness data that we might borrow from in considering IoT Systems data in smart cities and smart campuses. In their paper “Communication, Mediation, and the Expectations of Data: Data Valences Across Health and Wellness Communities,” Fiore-Gartland/Neff introduce the concept of data valences.

The authors identify six data valences:

  • self-evidence
  • actionability
  • connection
  • transparency
  • ’truthiness’
  • discovery

I’ll briefly describe these valences as I understand them and then suggest how they might be applied to an IoT System/Smart City System such as an energy management or smart grid system.

self-evidence valence

My interpretation of the self-evidence valence is that data is context-free or at least appears that way. The context-free-ness notion conflicts with the popular assumption of interpretation or mediation being required to make data meaningful as the researchers point out. My own opinion is that data does indeed need mediation to be relevant. In my mind, data without mediation devolves to the ‘just because’ answer. (While this can apply in parenting, eg ‘because I said so,’ it is extremely narrow in scope and its effectiveness has a much shorter timeline than I anticipated).

actionability valence

Actionability refers to the expectation that the data does something or drives something. From the context of the data consumer, can that data be used to do something meaningful for that consumer within their context? Fiore-Gartland/Neff give the example of a physician being presented with self-collected patient data. This may well not be “clinically actionable” because the physician has no basis for comparison or reference.

connection valence

This valence identifies data as a ‘site for conversation.’ To me, this one is particularly meaty. Because regardless of all of the other (important) valences, the connection valence draws people to the same table to discuss data for one reason or another. An example given in the paper is that of a home patient contacting their case manager about data being collected as a part of the telemedicine system. The call was not particularly important regarding the telemedicine question, but rather because it provided an opportunity for the case manager and patient to connect and share other information (which might have been written on the margins of a legal pad).

Even if the data-discussion reasons are possibly simple or seem unrelated to ostensible objectives, people are still showing up for whatever reason and in the course of that showing up, other things are shared and communicated. I believe that is a powerful valence. And possibly not easily quantifiable.

transparency valence

The transparency data valence is pretty much what it sounds like. It’s the idea or expectation of real or perceived benefit of data being “accessible, open, sharable, or comparable across multiple contexts.” As the researchers state,“Making data transparent across communities is one set of values or expectations.” The transparency valence also introduces the idea that when there is data transparency, when it is indeed shared across contexts, then new questions around ownership, access, and confidentiality present themselves. And from my perspective, addressing these new questions/issues is important work and requires some resources – time/effort/maybe dollars – and that has to come from somewhere.

truthiness valence

Stephen Colbert introduced the word truthiness during one of his shows. He uses truthiness, or the Dog Latin version “veritasiness” to describe something that feels right or just seems right, often regardless of facts or evidence. (Self-referentially, I think the idea of ’truthiness’ itself also seems right – most of us think, “yes, I understand what truthiness is. I don’t know why, but I’m pretty sure I know what it is.”

So the truthiness data valence has to do with the data quality of feeling right or seeming right.

discovery valence

Per Fiore-Gartland/Neff, the discovery valence “describes how people expect data to be the source or site of discovery of an otherwise obscured phenomenon, issue, relationship, or state.” This is not inconsistent with the popular notion of Big Data — which generally goes something like, ‘because there’s so much data there, there’s got to be something there – patterns, knowledge, etc and we can find it intentionally or accidentally’. I’m not saying that I subscribe to this, but it seems right (see ‘truthiness’ above).

Data valences in an IoT System example – smart grid

Because I’ve spent some time working with and reflecting on the challenges of implementing and managing a long-term institutional energy management system and the associated cultural and organizational challenges needed to be effective, the data valences idea proposed by the authors has made for highly relevant conversation.

So how might the six data valences reveal themselves in an institutional energy management system such as a smart grid system or a part of a smart grid system — themselves IoT Systems? Below is my take on how each of these valences might come into play in this context.

self-evidence valence in energy management data

My initial reaction is that I don’t see this valence playing out particularly well here. This energy management data sourced from thousands of energy sensors across an institution needs to have context and be interpreted to have relevance. Also, the data is too new and unfamiliar and often complex for there to be strong statements of self-evidence.

That said, the topic of climate change and all the misinterpretations and rhetoric therein comes to mind. So maybe the self-evidence valence has applicability here as well. Perhaps conclusions will indeed be drawn from energy data devoid of context.

actionability valence in energy management data

Definitely. Everyone — consumers, vendors, government, others — expect to do something useful here.

connection valence in energy management data

Definitely again. This data provides the site, as the authors say, to come together to problem-solve. And in the course of that problem-solving, a parade of assumptions and expectations come quickly to the surface. Finance people , energy management people, IT and data people, vendors, and a variety of end-users bring their expectations, assumptions, and desires to these meetings. This data valence is particularly important at this stage of the game regarding energy management systems and likely IoT Systems more generally.

transparency valence in energy management data

Yup. Everybody wants this. Much like youthful dating, this distribution of data interpretation across contexts is exciting, challenging, and fraught with peril for misunderstanding. That said, addressing topics around this valence can bring important issues to the surface (though it’s typically a lot of work).

truthiness in energy management data

I’m not sure about the truthiness valence in institutional energy management data. Similar to the self-evidence valence, I don’t know that we have enough exposure to the data to have a truthiness feel about institutional energy management data. But again, misinterpreting climate change data has become a worldwide sport.

discovery valence in energy management data

Without a doubt. Almost all of us have this expectation of discovery, at least at some point — Start capturing energy data and we’ll make awesome decisions !! I do believe that capturing this data will yield useful, actionable (see above) data. However, I think it’s going to be more work than is immediately apparent.

Data valences in IoT Systems

How we, across our multiple constituencies within an institution, perceive various aspects of data has a strong influence on the perceived success of the system that produced the data. This is true for institutional energy management systems and I believe that that is broadly generalizable to IoT Systems of whatever institutional purpose.

Understanding data perceptions across an institution or population base is essential for successful IoT System implementations and hence Smart City or Smart Campus implementations. As I mentioned in the IoT Systems Hamburger Diagram, while not sexy and ‘blingy‘, the capability and capacity of an institution to implement complex IoT Systems in a complex environment is essential to success. Understanding the varied data consumers and their perceptions and needs in a complex organization such as a city or campus is, in turn, a critical component to a successful IoT System implementation.

Organizational-spanning characteristics of IoT Systems

1 Reply
Gaps between institutional organizations implementing & supporting IoT Systems create challenges

Gaps between institutional organizations implementing & supporting IoT Systems create challenges

One of the unique characteristics of IoT Systems, and one that adds to the complexity of a system’s deployment, is that they tend to span many organizations and entities within the institution. This is particularly true in Higher Education institutions with their city-like aspects, multiple service lines, and wide variety of activities in their buildings and spaces. While traditional enterprise systems, such as e-mail or calendaring, are likely to be owned and operated by one or two institutional organizations, IoT Systems involve many and are deployed in the ‘complex and material manifestations’ that characterize buildings and spaces.

A Higher Education institution example might be a research lab that incorporates an automation and environmental control system that involves the facilities organization, the central IT organization, maybe a local/distributed IT organization, the lead researcher (aka Principal Investigator or PI), her lab team, at least one vendor/contractor and probably several other vendors. Between each of these, a gap forms where system ownership and accountability can fall. Everyone sees their piece, but not much of the others. There’s no one monitoring the greater Gestalt of the IoT System. And that’s where the wild things are.

Traditional enterprise systems tend to fall within the domain of central IT with use of the system being distributed around the institution. So with traditional enterprise systems, use is distributed but ownership and operation is largely with one organization. IoT Systems, on the other hand, tend to have multiple parties/organizations involved in the implementation and management, but the ownership is unclear.

IoT Systems are systems within systems within systems ...

IoT Systems are systems within systems within systems …

This lack of ownership can lead to unfortunate assumptions. For example, the end user/researcher in the Higher Ed case is probably thinking, “central IT and the Chief Information Security Officer are ensuring my system is safe and secure.” The central IT group is thinking, “I’ve got no idea what they’re plugging into the network down there … I didn’t even know they bought a new system. Where did that come from? “ The facilities people might be thinking, “Okay I’ll install these 100 sensors and 50 actuators around this building and these two computers in the closet that the vendor said I had to install. The research people and central IT people will make sure it’s all configured properly.” No one is seeing the whole picture or managing the whole system to desired outcomes.

This implementation and management of IoT Systems is a part of what is being explored within Internet2’s IoT Systems Risk Management Task Force in support of  Internet2’s  Smart Campus Initiative.

Technology adoption in other aspects of the building industry

Research has been done in other areas of technology implementation in the building, space, and campus realms that might help shed some light on the multi-organizational challenge that IoT system implementations can bring to institutions.

Research in the Building Information Modeling (BIM) field suggests that buildings have a ‘complex social and material manifestation … [that requires] a shared frame of reference to create.’ Building Information Modeling seeks to codify or digitize the physical aspects of a space or place such that its attributes can be stored, transmitted, exchanged in a way that supports decision-making and analysis.

In their paper, “Organizational Divisions in BIM-Enabled Commercial Construction”, researchers Carrie Dossick and Gina Neff identify competing obligations within supporting/contributing organizations that limit technology adoption.  They point out that BIM-enabled projects are “often tightly coupled technologically, but divided organizationally.” I believe that their observations regarding BIM projects also share common aspects of deploying and managing IoT Systems.

The Dossick/Neff research suggests that mechanical, electrical, plumbing, and fire life safety systems can be as much as 40% of the commercial construction project scope.It is likely that this number will only increase as our buildings and spaces become more alive, aware, and aggregating of information of what goes on in and around these spaces.

For the BIM implementations studied, the research suggests that there are three obligations of the people and groups contributing to the effort and that these can be in conflict with each other.  The obligations are: scope, project, and company.

As I interpret the paper, scope obligation is what a person or group is supposed to accomplish for the effort – what are they tasked to do. That mission is not overarching organization and coordination of the project, but rather specific, often local, tasks that must be done in support of the effort. In the course of that work, participants in the work are naturally “advocating for their particular system.“

Projects bring together temporary teams for a particular purpose. These time boundaries and purpose boundaries create the environment for the project obligation. Specific timelines and milestones can drive the project obligation. This area can be particularly challenging as it can involve negotiations among different providers, the interests of owners, and design requirements.

Finally, obligations to company “emphasize the financial, legal, and logistical requirements” where ownership and management provide the environment and context in which work is done. This also makes sense intuitively as company is whence one’s paycheck comes. Performance today can influence today’s paycheck as well as paychecks down the road.

While not exactly the same, I think there are some parallels with IoT Systems implementation and management.

BIM implementation/adoption -> IoT Systems implementation & management

  • scope -> scope
  • project -> project
  • company -> department/organization

To me, organizational aspects of scope and project are very similar between IoT Systems implementation/management and those observed and analyzed by the research in BIM implementation.

For IoT Systems implementation and management within an institution, internal departments and internal organizations can closely parallel that of the company that the research addresses. A person’s or group’s directives, performance expectations, and paycheck approval ultimately comes from that department or organization so there will be natural alignment there.

Leadership ‘glue’ has its limits

Finally, the paper also points out the role of leadership in an effort where there is new technology to potentially be adopted or leveraged. While strong leadership is clearly desirable, the research suggests that even good leaders often cannot overcome structural organizational problems with great efficiency or effectiveness. The authors also note that research does not yet understand what “organizational resources to be in place for effective collaboration to occur after new technologies are introduced.”

IoT System ownership for implementation & management

Like BIM and related technology adoption, I believe successful IoT Systems implementations have similar institutional organizational challenges. IoT Systems implementations are themselves a part of larger system of institution, organizations, and people. IoT System implementation and management success will, I believe, also require learning to work with these multiple organizations that have inherent competing obligations. While there may be other approaches to evolve to solve these organizational challenges, a reasonable place to start in the near term might be to establish organizational-spanning system ownership and accountability.