Cubicon Platform:
Roadmap to a Smart Grid

Introduction

CoreTalk is developing the Cubicon Platform, targeted for deployment in complex hyper-networks that require high levels of interoperability, such as a future Smart Grid. The platform is suited for general grid and hyper-parallel applications as well. Cubicon supports the intelligence for this future infrastructure by automating the integration and interoperation of every facet of energy producing and consuming systems.

Cubicon Platform

The Cubicon Platform consists of the following elements that will interoperate in a new intelligent Internet layer called the Semantic Net (sNet). The platform supports context processing, and provides order-of-magnitude advancements in the development, management, and execution of distributed systems:

Meta-standard Architecture

Cubicon is a meta-standard architecture, built for the purpose of separating context from content. The ability to communicate the meaning of data (meta-level), in addition to the data itself is the true definition of semantic computing. Successfully making computers intelligent opens the floodgates to the creation of new markets and commerce models. The field of semantic computing was inspired by current demand for a next generation Internet infrastructure that supports information processing in context.

Cubicon is a unified and heterogeneous global Intelligent Infrastructure, with elements that are recombinant and secure to Net-scale. It covers the full spectrum of complexity issues ranging from community formation to detailed systems implementation and evolution.

CoreTalk is proposing a new method to create and distribute software systems as Intellectual Property (IP) components, called Design Source. Authors creating these components can receive direct compensation for their contributions through virtual supply chains. For example, new markets can emerge, composed of sophisticated component frameworks that combine complex sensor, control, and energy metering algorithms for sale and reuse within various producing and consuming systems.

Smart Grid System

A Smart Grid System will consist of interactions between hyper-networked devices, supported by a common underlying semantic architecture. This Grid will be able to intelligently link all consuming devices located in residential, commercial, or industrial settings, directly to energy producing facilities. Device manufacturers will organize into specialized communities to develop sensor and controller hierarchies that classify and publish interface specifications in this device plug-and-play ecosystem. Fine-grain control functions in the Cubicon suite of technologies will optimize the energy consumption of these devices, based on realtime peak demand curtailment, and the distribution of power between energy producers. The GridWise community can develop system interoperability macro-standards that can be easily adopted by its Alliance membership.

GridWise Interoperability Context-Setting Framework

This Cubicon Architecture paper cites excerpts from the "GridWise Interoperability Context-Setting Framework" document so noted in "italic" text. The full GWAC document can be downloaded through the following link: GridWise Interoperability Framework
(http://www.coretalk.net/CubiconPrivate/GridwiseInteropframework.pdf)

The cross-cutting issues detailed in this document are areas of the framework that need to be addressed and agreed on to achieve systems interoperability. The remainder of this paper is divided into two sections: Interoperability Categories and Cross-cutting Issues sections.

Interoperability Categories

Technical Aspects

1. Basic Connectivity

The Basic Connectivity category focuses on digital exchange of data between two systems and the establishment of a reliable communications path.

The Cubicon Intelligent Infrastructure establishes communication paths through both IPv4 and IPv6 Internet protocols, as well as interacting seamlessly with emerging Low power and Lossy Network (LLN) protocols. LLN sub-networks will encompass:

2. Network Interoperability

The Cubicon Intelligent Infrastructure will reliably transport information through asynchronous message, dialog service, and transaction closure methods.

An asynchronous message mechanism in the Cubicon VM replaces the existing Remote Procedure Call (RPC) mechanism currently used over the Internet, and in LLN sub-networks. An asynchronous message mechanism allows direct communication between objects located in different devices. Object-to-object linking is limited to only devices owned and controlled by a single entity (person or organization). A person with limited programming skills will be able to implement fine-grain interactions between objects, a nearly impossible feat in the current Internet infrastructure. The common underlying Cubicon architecture allows any device from any manufacturer to function interactively. Think of this capability as a "Twitter" for machine-to-machine interactions, but limited only to an entity's domain.

A residential example would be allowing a consumer the ability to program their cell phone to remotely monitor and control a home energy-consuming device without involving a specialist. A commercial example would be to coordinate the controls between solar blind and HVAC systems to leverage night purge, pre-cool and daylight harvesting strategies. An industrial example would be to regulate a greenhouse temperature based on dynamic weather conditions.

A dialog service is an interaction between devices that takes place at wire speed. A service can be sent between devices owned by different entities, as the Cubicon Intelligent Infrastructure authenticates both parties before they participate to prevent unauthorized communication. These dialogs may include intelligent routing, based on Deep Packet Inspection (DPI) of the service content. As a core network example, advanced routing can be used to automatically reroute services between energy devices, based on events detected deep in the network's infrastructure. As an edge network example, realtime service interactions can be used to regulate the distance between traveling vehicles using a future autonomous highway guidance system, thus decreasing traffic congestion and maximizing energy efficiency.

A transaction closure is an interaction that allows independent tasks to simultaneously read-and-write to the same object(s), and assures that all data-state changes are performed within an atomic boundary. Closures can be nested so that an inner transaction can be committed or rolled backed without affecting an outer transaction. Multiple closures may be expressed within a process-flow space by specifying their dependencies beforehand. A transaction closure can express a hyper-parallel procedure across manycore processors and network nodes to execute heterogeneous parallelism. An example would be enabling an energy-trading partner to process monetary exchanges associated with power transfers across a distribution grid. The Cubicon icon-based language simplifies the creation of these types of blended, transactional/Business Process Management (BPM) applications.

3. Syntactic Interoperability

All Cubicon services (content) are composed of compact and efficient binary composite structures that are processed without parsing by the VM. Each VM obtains service-decoding instructions (context) on demand from shared Community Repositories. Each repository resides within an entity's domain space and can be moved between local and ambient (cloud) locations. This method of separating context from content is the essence of context processing. It supports multiple service versions and a smart Application Programming Interface (API). A Cubicon manifest is a type of API that allows graceful shared service upgrades without breaking their interactions with local realtime devices. For example, any device, ranging from a wall thermostat to a generator governor, can be dynamically added or removed from the Smart Grid using a manifest.

Informational Aspects

4. Semantic Understanding

Contextual processing of systems takes place within a particular set of circumstances, dictated by an entity, that support the common meaning of system components within the confines of a community. Individual communities of practice form within a particular domain based on common interests and interoperability requirements, to develop their own device functionality and service interfaces. A Cubicon community automates the entire lifecycle of device and service specifications to deal with evolving requirements from a collective membership. For example, each thermostat manufacturer develops monitoring and control specifications for each device they produce. The manufacturers join a community to agree on a common thermostat interface (a set of service manifests.) All manufacturers' conform to these manifests to enable device interoperability. Each manifest is the common agreement that allows for plug-and-play in the field, even though each device's functionality can ultimately remain proprietary. In services, this meta-level architecture can be applied to any device found in residential, building, industrial, transportation, and environmental systems.

The icon-based language is composed of 20 elements that serve the same purpose as language constructs in traditional textual languages. Cubicon language elements represent programming abstractions, like a unit of measure, attribute, method, object, etc. Community members combine elements into system components, based on a set of immutable language rules. Within a community, each element is permanently assigned a unique Global IDentifier number (GID) when it is created. Community members can also link multiple natural language and dialog names to each element to aid in local recognition. Elements are a significant part of this architecture, as they allow all software components built from them to remain recombinant and reusable throughout the ecosystem.

5. Business Context

Architectural requirements for a future Smart Grid will need to combine both realtime and transaction systems to be able to perform fine-grain interactions. A community member can use the icon-based language to express both control-flow and process-flow methods. These multi-paradigm language expressions can be effectively applied to a wide spectrum of programming domains. Currently, different domains require their own scripting language, preventing interfacing and execution coherence between them. Realtime, reactive, state-driven systems and concurrent tasks in business transactions can be expressed simultaneously by the use of a single icon-based language. Cubicon automation gives a much larger population of staff specialists the ability to engineer complex energy systems without involving a software engineer. For example, when the power of a generator is monitored in realtime and tied to a negotiated contract for an energy exchange, or when a regional reliability coordination center is monitoring load curtailment. In both cases, a staff specialist would be able to fine-tune the distributed algorithms without necessary involving a software engineer.

Organizational Aspects

6. Business Procedures

A Cubicon community membership cuts across companies and countries. A community enables interoperability between processes and procedures by automating the collaborative design process itself, allowing systems to readily span application boundaries. Automation at this level provides inherent flexibility to distributed systems, so entities can fine-tune monitoring and control strategies for their realtime devices while continuing to meet community objectives. An example of interoperability in the field of energy management would be an electricity provider negotiating a contract for emergency load curtailment directly with a consumer so local thermostat set points are adjusted automatically to maintain the balance between load shedding and a minimally acceptable occupant comfort level.

7. Business Objectives

A community may elect to share components, represented as Intellectual Property products, with other communities through automated linking mechanisms in the Cubicon IP Exchange. IP products can be assembled for sale and reuse in this future virtual market. For example, the energy production industry can direct realtime energy flows using congestion management forecasting tools that will manage distribution feeders and transaction flows. The icon-based language allows these types of complex programs to be represented as software components, owned by NERC/ERO standards organizations, or a set of IRC members who can sell complex components to other energy organizations.

8. Economic/Regulatory Policy

Cubicon communities support policy driven decision-making over vast and distributed knowledge bases. An individual community acquires and maintains knowledge, and provides a setting conducive to interoperability. Communities support efficient information integration and knowledge virtualization, regardless of the originating source. Source examples might be dynamic energy market, customer, or internal operations information.

The icon-based language scales globally. Its iconic expressions are concept-based, making them independent of natural language. Iconic designs appear within the Cubicon IDE (Integrated Development Environment) in the natural language of the member. This feature can even be as specialized as an organization's internal dialect. Conversion from the base community language can be semi-automatic, based on a commercial translation tool allowing a community member to fine-tune concepts, components, and comments into their foreign termspace and namespace.

Many "upper ontology" standards will evolve in different communities and uncover concept and component overlaps that are good candidates for consolidation. For example, a NIST-controlled community establishes a set of energy measurement components that all world communities could then share electronically. Any component change that NIST institutes could automatically be distributed, and selectively adopted by other communities for instant download into millions of synchronized devices. An outside community creating a similar component could elect to substitute their specification with the NIST component, resulting in the outside membership devices automatically linking to and executing the instructions for the replacement component.

Crosscutting Issues

A. Shared Meaning of Content

Cubicon is a meta-specification technology that communities can use to develop and maintain specifications and standards within their domain. For example, specifications in the energy systems industry may represent metering, AMI device control, grid integration, energy management, distribution management, transformer monitoring, and other grid subsystems. Ontology-based domain descriptions that contain Cubicon metadata will set the context for message exchange, and ensure concise understanding of intent across all communicating devices. Cubicon ontology easily extends to existing grid-specific standards and regulations (IEC 61850, IEC 61970, IEC 61400-25, etc.) as well as regulations that will be established in the future.

The Cubicon architecture maps both the universal concept and particular system knowledge space within community contexts. Common semantics between concept terms and system components are based on genealogy and composition schemata. Two linking mechanisms, called copy and referral, allow the sharing of selected concepts or components between communities.

A VM interprets content based on specific context instructions that it must first receive from a community, so that processed meaning of information remains absolute and secure within devices.

It is practical to merge or divest some, or all, of a community's Intellectual Property to other communities. This may occur when two communities discover overlapping charters, or if a community becomes too complex to effectively manage the entire body of component specifications. These restructuring actions can easily be accomplished with several mouse clicks. Advanced community management functions are possible because all communities share a common meta-architecture, represented in located in repositories. All Cubicon repositories use identical composition tree schemas. This commonality is crucial to maintaining the recombinant nature of Cubicon software components.

B. Resource Identification

The icon-based language has an elaborate global IDentifier number (GID) structure (over 30 orthogonal dimensions) that satisfies all current and future Smart Grid architecture requirements to uniquely identify every device and software component in the world. The identity base starts with a unique entity number assigned by CoreTalk to each person or organization that joins the ecosystem. An entity can create one or more numbered communities under their ownership, and accept other entities as members. A context component located in a community is composed of sub-component language element types, each with its own designated number series for every instance of each type. For example, a context number series is designated context (AID), data (BID), template (CID), etc. and so on through all 30 dimensions. Accordingly, each component identifier is a composite of a unique combination of entity/community/element numbers. This multi-dimensional architecture scales to trillions of combinations and assures that no identity clashes will occur.

An entity operates one or more physical devices that can execute these community-bound system components. Device manufacturers can freely develop controllers, and publish their service interfaces with the assurance that no identification conflict will occur. For example, a HVAC contractor can access a thermostat manufacturer's published service manifest to understand the precise device specifications that could very well include the internal algorithms of the microcontroller. These specifications are dynamically represented in Cubicon executable designs and are far more advanced than static XML-based specifications.

C. Time Synchronization and Sequencing

In the icon-based language, a common expression, such as time, may be represented as a component that community member devices can properly translate within their time zones. Quality-of-service, as well as sequencing semantics, can also be centrally standardized, with downstream, communities declaring local behavioral overrides if local circumstance dictate. Translation redefinitions that meet realtime requirements are simple to declare in the icon-based language.

A system executing in the Cubicon Intelligent Infrastructure will deterministically react to microsecond environmental and machinery events in realtime. These systems execute in a VM that performs garbage collection (GC) events in microseconds to assure deterministic system behavior. Efficient control-flow behavior is designed completely from icon-based language elements without workaround of the VM's distilled instructions, to achieve high performance execution in even the most demanding temporal environments. Eliminating code workaround is one inherent design tenet of Cubicon architecture that ensures Smart Grid security, because rogue software cannot be nserted into the environment.

D. Security and Privacy

Confidentiality — Service exchanges are transported in binary and can only be effectively interpreted by a device's VM that must first obtain processing instructions from its source Community Repository. The device's controlling entity must be a community member to download service process instructions into the VM. Encrypting the service content remains optional.

Integrity — An instance of a Cubicon service is pure content and does not contain any "markup". A VM that obtains processing instructions from a Community Repository can copy data values in and out of the service instance, as well as edit its composite tree structures. Any attempt to alter or insert rogue content into a data structure is detected and generates a program exception that can trigger a rescue method.

Availability — A responding entity can restrict certain service attributes from transport to a particular requesting entity. These stateful service dialogs are managed with the assurance that particular response deadlines are being met. For example, a supervisory controller might request a power generator respond with its operating conditions on a periodic basis. Any interruption of this dialog would generate a fault condition.

Accountability — An entity has the option to log all incoming and outgoing service dialogs to provide an immutable historic trail of all business and control system interactions.

E. Logging and Auditing

A VM has the ability to log both service interactions and task transactions. All logged information is recorded within the context of a community so that archives can be processed across organizational boundaries. File, relational, object, and XML, data can be converted into Cubicon contextualized data, since it is a superset of all four legacy models.

F. Transaction and State Management

The VM incorporates both service and transaction mechanisms that serve separate, yet complementary, functions over TCP/IP. These mechanisms maintain data integrity and processing consistency during fault conditions that may interrupt complex distributed operations. A Net Closure is a stateless synchronous communication transaction mechanism, and a Net Service is a stateful asynchronous communication mechanism.

A Net Closure will automate the connection of stateless systems, based on transactions. A closure takes a lock on a set of remote system data, and assures that its state is preserved until the transaction is either committed or aborted, within an atomic boundary. A closure can be driven by a process task, a window/pane client, a host API, or an object message. This type of closure can provide the Smart Grid with a rich tapestry of mechanisms to interact seamlessly with outside organization such as transportation, homeland security, and other government and private sector systems.

A Net Service protocol will automate the connection of stateful systems, so that collaborating machines understand the information they are transporting and processing. Common service information is passed between disparate devices that perform discrete processing on a dialog basis that takes place for any length of time from milliseconds to hours.

G. System Preservation

The VM uses a synchronous reactive model of computation to ensure deterministic system behavior. This model also supports finite state machines and formal assertion/exception handling, expressed as iconic language elements. The model and its elements operate within intrinsically secure VMs, and provide the sophisticated control and monitoring algorithms required to manage a myriad of devices, from discrete controllers to swarms of environmental sensors.

If a collaborating device looses communication, it can operate autonomously and continue to maintain its own state space. An example of system preservation is a thermostat normally under central control reverting to a default set point if it temporarily looses connectivity. Every VM embedded in a device stores its content data locally, and periodically receiving context behavior (application program) version updates from their respective entity and community repositories. Redundant repositories can be mirrored in the cloud, in case of network or storage failure, to provide backup.

H. Quality of Service

Cubicon micromachines automate tasks directly associated with the construction and management of software systems. The concept of a micromachine is borrowed from the emerging nanotechnology field, where micro-electromechanical machines perform some useful task. Micromachines fuse the worlds of hardware and software by automating specifications into executable designs. Simplification of the software life cycle is achieved by removing the impedance mismatch between hardware and software model representations. A system expressed in the Cubicon icon-based language is a virtual design, expressed in a set language element patterns. These semantically-based solutions can be represented in software, or synthesized into hardware. An iconic language will enable a much wider population of professionals, with varying levels of programming skill, to participate more directly in engineering secure and robust solutions that may even deal with extreme conditions, and exceptional events.

The Cubicon Platform can help organizations meet stringent infrastructure requirements by automating the development and deployment of complex distributed systems. It provides the response time, reliability, accuracy, and deterministic qualities required in an advanced Smart Grid.

I. Discovery and Configuration

Micromachine compatibility throughout Cubicon Intelligent Infrastructure ensures that diverse components and services authored by different communities always remain as recombinant Intellectual Property (IP). The overriding challenge of reusing existing IP is one of discovery. How does an IP consumer find out what is available from global component and service resource suppliers? The Cubicon Context Registry provides both pull and push discovery mechanisms.

The pull discovery method establishes search criteria based on entity, community, service responder, net resource, or topic map predicates.

The push discovery method is based on the fact that Cubicon architecture is recombinant, making it easy to infer relationships between components. Deduction and inference of underlying genealogy provide automatic discovery of related context, and other components, without explicit search. Based on push discovery, a community may reuse components through three forms of sharing: copy, referral, or merge.

Each physical device can publish its internal program specifications as well as a set of service manifests. Program specifications can be selectively disclosed in multiple layers of detail, down to iconic operational behavior. Service manifest specifications show precisely how to develop a set of connectors that can interact with one or more host applications. The Cubicon Context Registry provides the capability to locate and integrate millions of devices by aggregating and then publishing the resulting specifications across communities.

A service can evolve through multiple versions, receiving input from community members. This input is then recorded as embedded comments throughout the evolution of the component. Services can then be instantly downloaded into multiple devices, and executed without the need for static instruction compiling or dynamic service parsing., The elimination of these transformations simplify development and increase processing efficiency. Service architecture supports independent device processing, while maintaining a common dialog between them. Therefore, any controlled device or sensor that is connected to a VM can be added to or subtracted from the Smart Grid on a plug-and-play basis.

J. System Evolution and Scalability

The inherent intelligence in Cubicon architecture allows a high degree of reuse, and the ability to make frequent and significant modifications to distributed systems, in a cost effective manner.

A Cubicon community effectively manages the versioning of a software component's internal operations, as well as its interface with external applications and systems at Net-scale. The automation of software management allows communities to fluidly advance their component specifications to meet ever-changing systems requirements, without becoming brittle.

Internally, a micromachine-based component assembly automatically manages the genealogy, composition, and network aspects of systems representation. This novel technology feature allows diverse community members to participate in component development across multiple clone, draft, published, expired, and obsolete, versions that may ultimately execute in tandem across different devices.

Externally, a manifest serializes a composite tree structure binding each element attribute to a programmatic call interface during the service design phase. A host application can write element attribute data into the service through its API during execution. A designated community member edits the service specification to meet changing requirements. A developer performing back-end application maintenance is automatically notified when the community at large has released a new service version. The developer accesses the service manifest that indicates which elements and their attributes have been created, modified, or deleted.

Conclusion

The GridWise Alliance is chartered with "rethinking energy from generation to consumption". The Cubicon Platform will greatly accelerate meeting these goals, and provide the infrastructure for a future national Smart Grid.

email: klausner@coretalk.net
Roadmap to a Smart Grid

Contact: Sanford B. Klausner, Founder and CEO
408.621.4709