Reconsidering Information Systems Infrastructure 37

This is the 37th posting to a series that I am developing, with a goal of analyzing and discussing how artificial intelligence and the emergence of artificial intelligent agents will transform the electronic and online-enabled information management systems that we have and use. See Ubiquitous Computing and Communications – everywhere all the time 2 and its Page 3 and Page 4 continuations, postings 374 and loosely following for Parts 1-36. And also see two benchmark postings that I initially wrote just over six years apart but that together provided much of the specific impetus for my writing this series: Assumption 6 – The fallacy of the Singularity and the Fallacy of Simple Linear Progression – finding a middle ground and a late 2017 follow-up to that posting.

I have been discussing a set of topic points that I repeat here from its Point 3 on for smoother continuity of narrative:

3. How people or other input providing agents who would work with and make use of these (n.b. complex and wide-ranging) systems, simplifying or adding complexity to the contexts that a task performing agent would have to perform in, could shift tasks and goals actually required of them either more towards the simple and fully specified or more towards the complex and open-ended.
4. And the issues of how an open ended task to be worked upon and goal to be achieved for it, would be initially outlined and presented. (This is one of the points in this series in which I would make use of the adaptive peak model of evolutionary, or in this case ontogenetic development.)

To bring this initial orienting note up to date here, I am currently focusing on addressing Point 3 in this developing narrative. Though looking ahead, I have also at least preliminarily touched upon the role that adaptability plays there too (in Part 36.) And I concluded that installment by noting that I would continue its line of discussion here, turning to the role of Supervisory Control and Data Acquisition (SCADA) systems in complex infrastructures (such as the large scale petrochemical refineries that I have been discussing for didactic purposes here, as a source of working examples.)

That noted, I have been discussing the above Point 3 in terms of two specific subtopic points:

• Distributed management and supervision systems, and their hierarchical and top-down counterparts as their implementation might enter into this,
• And the question of what criteria should best govern the management of what agents and types of them as they would carry out what roles, of what types and where, and under what circumstances in complex flexible systems.

And my goal for this posting as I completed Part 36 was to complete an at-least first draft response to the first of those points and begin to address the second – doing so in the context of addressing the issues explicitly cited in Point 3 as it is phrased with its focus on coordinated, dependency based functionality. But on further thought, I have decided to start this posting’s line of discussion more explicitly from the perspective of that last to-address point of detail. And I begin doing so by posing a jigsaw puzzle analogy, noting that I am going to make use of this when addressing the issues of infrastructure systems building as a process of designing and assembling complex interactive networks of functional nodes that exhibit coordinated, dependency based functionality within and between them. And I will further consider the first of the above repeated subtopic points and start addressing the second of them in terms of that.

With this noted, let’s consider what a completed jigsaw puzzle is. It is a gap-free array of constituent pieces that are all shaped so as to fit and certainly optimally into their own specific places in that puzzle. Shape fit is important there. And when, as is usually the case, a completed jigsaw puzzle as a whole presents a consistent and gap free depiction of some specific visual image, collective overall correct placement of its parts completes that representation too as an information package.

• Think of a large and complex infrastructure system such as a large petrochemical refinery that is structurally complete and fully functionally enabled from that at any given point in time, as representing a large and complex three dimensional jigsaw puzzle. Or think of how such a refinery at the very least holds counterparts in its realization to the interconnecting details of my above puzzle description.
• Every piece in this refinery functionally connects to at least one other piece of it in supporting and carrying out at least one key aspect of the flow of processes that go into producing the complex array of petrochemical based products that such a facility would produce as a whole.
• It would also connect into and be functionally supported by and controlled by the SCADA system in place.
• Dependencies enter into this overall system in at least two fundamentally important ways:
• From how work process flows carried out by these parts take direct input from other, there functionally connected parts of it, and with them in turn providing such input to other parts of that system (as their explicit outputs.)
• And for how all of this is mapped into the information processing flows of the SCADA systems in place as it sets and then adjusts or switches as need be, work process flows taking place across arrays of such functional parts and subassemblies of them, and as that command, control and data acquisition system manages goals and priorities changes entered into it, concerning the balance of what is actively being produced at any given time.
• Any gaps in the physical processing and handling nodes and their essential connections in such a system would constitute fundamentally impactful points of systems failure for how they break the essential node-to-node functional dependency chains that enter into them. Consider by way of example, if a valve was to break, causing a flow of some specific distillate fraction or some catalyst needed to produce it to pour out onto the ground or onto the outside casings of other parts of this overall system instead. To take that out of the abstract, consider the consequences if the material so inadvertently released was like heated toluene with its corrosive and toxic properties. That would create risk for both the hardware in place in that system and for any personnel in that area as well, or downwind of it.

Choice of distributed, or of hierarchical and top-done systems architecture, or of some combination of them should depend on what has to be carried out, interconnected step by interconnected step in such an overall system, and by how steps of the overall process flows to be carried out there logically group together for their functional dependencies and for their necessary physical proximity and connectedness. Risk management enters into this too where keeping some sets of functional nodes in such a system physically separated from each other as a safety measure, can be just as important as placing them closer together would be where that would create positive value. And as I have already noted in this type of context in discussion here, some areas of a complex system of this type would best come together as distributed controlled distinct subsystems, others might very well require direct top-down hierarchically structured control, with specific hierarchically placed safeguards built into them. But even where top-down normative systems control would be best, lower level and bottom level on up feedback is essential and particularly for catching and responding to sudden component or subsystem failures and as quickly as possible.

This addresses the physical hardware side of these systems, and certainly as the issues that I have been raising here emerge in the context of this working example. An effective SCADA system maps directly and in an equally gap-free manner onto the physical system that it is intended to supervise and control. And it is there that the specific wording offered in the above Point 3 enters this narrative and adaptively so, as physically controlled nodes in such a system and the complexity of their dependency-based functions and interactions that connect them need to vary.

I am going to continue this line of discussion, and from a SCADA systems perspective in the next installment to this series. This will mean my more fully addressing the specific issues raised in main topic Point 3 and more explicitly addressing the second of two subtopic points as repeated above, though I will more explicitly discuss the first of those subtopic points there too. And then looking further ahead, I will explicitly address topic Point 4 too.

Meanwhile, you can find this and related postings and series at Ubiquitous Computing and Communications – everywhere all the time and its Page 2 and Page 3 and Page 4 continuations. And you can also find links to this posting and others in this series, appended to the end of Section I of Reexamining the Fundamentals as a supplemental entry there.