7. Design Principles¶
The Grid Edge Interoperability & Security Alliance specification is written for constrained resource embedded industrial devices. A constrained embedded industrial device may consist of a simple microcontroller (e.g. Cortex-M class core), a more complex microprocessor (e.g. Cortex-A class core), or a heterogeneous or modular environment with both.
These devices are expected to operate in the field without manual intervention for prolonged periods of time; often two decades or longer. While these devices have network interfaces and sensors (see Hardware Expectations) they do not typically have on-board (graphical) user interfaces.
This device target informs the overall design principles of the specification.
GEISA design principles include:
Interoperability
Constrained Environment
Minimal Implementation
Core Specification with Extensions
Security
Each design principle is described in more detail below.
7.1. Interoperability¶
As discussed in the Introduction, GEISA defines four types of interoperability:
- LEE
Linux Execution Environment LEE interoperability
provides a consistent operating
system environment built using Linux.
The Linux Execution Environment provides a well-known open development
environment including many standard libraries and makes it easy to integrate
additional technology.Applications written for the GEISA LEE will run on any LEE-conformant device.
- VEE
Virtual Execution Environment
VEE interoperability
provides a consistent virtual
execution environment. The Virtual Execution Environment provides a
fully-isolated managed code environment which supports the widely-used C/C++
and Java ® language specifications.Applications written for the GEISA VEE will run on any VEE-conformant device.
- ADM
Application and Device Management ADM interoperability
enables conformant devices to
interoperate with conformant management systems.- APIs
Application Programming Interface API interoperability
provides consistent access to
resources such as sensors, actuators, networking, and more.
Note that GEISA does not currently provide a tool-chain or a base-platform implementation. [1]
This release of the GEISA specification defines source-code interoperability for the LEE, VEE, & API, and network interoperability for ADM.
Source written for the GEISA LEE should be compilable without modification, and without needing conditional compilation or platform specific directives. Similarly, source written for the GEISA VEE should be compilable for the target virtual execution environment with needing conditional compilation or platform-specific directives.
As an example, shown below is a “do-nothing” C source code program that should compile using any GEISA LEE toolchain, producing an executable that runs on any GEISA LEE.
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
while(1) {
sleep(60); // sleep for 60 seconds
}
return 0;
}
As another example, shown below is a “do-nothing” Java source code program that should compile using any GEISA VEE toolchain, producing an executable that runs on any GEISA VEE.
public class GeisaHello {
public static void main(String[] args) {
while (true) {
try {
Thread.sleep(60000); // sleep for 60 seconds (60,000 milliseconds)
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
Warning
The LEE and VEE are two different environments. The LEE is specifically a Linux environment.
The VEE is agnostic to the underlying OS/RTOS, providing source-level interoperability through supporting well-known languages.
It is possible that a platform may support both LEE and VEE. In this case, an application developer may need to determine the proper methods that allows it to run on one or both execution environments when properly packaged. System operators may need to select applications according to the provided EE.
See System Architecture for further discussion.
7.2. Constrained Environment¶
The GEISA EE is a minimal resource environment, having constraints on CPU, RAM, storage, and networking. See Hardware Expectations for specific minimums that the GEISA specification assumes.
As much as possible, resources should be reserved for GEISA applications, instead of being consumed by the underlying operating system. While a GEISA conformant EE may offer more, it MUST reserve the following MINIMUM resources available for GEISA applications:
For GEISA LEE
:256MB of RAM
256MB of persistent storage
For GEISA VEE
:1 MB of RAM
8 MB of Flash memory for code storage and execution
8 MB of persistent storage
Additionally, although hardware performance will vary considerably between
platforms, GEISA EE SHOULD provide a minimum of 50% of the CPU for GEISA
applications 
.
Efficiency is critical. The GEISA EE shall provide only those services which are so widely required that it would be less efficient to not provide them.
7.3. Minimal Implementation¶
Keeping systems up-to-date is challenging, both for utilities and for vendors. The GEISA EE favors the minimal implementation; that is, the less there is, the less there is to maintain and the less there is to attack.
If there is an option that is not needed, then turn it off. If there is an unwanted or un-necessary feature, leave it out. GEISA should include only what is required.
7.4. Core Specification with Extensions¶
In addition to the four keys aspects of interoperability (ADM, API, LEE, and VEE), future extensions may be added to to the GEISA specification may be added as the community determines the need.
Future extensions may define new areas of interoperability conformance beyond ADM, API, LEE, and VEE, or they may enable new capabilities that are only needed by selected devices types or in specific markets. Extensions will allow GEISA to retain its Minimal Implementation design principle, while still allowing it to grow to meet the needs of platform vendors, application developers, and system operators.
7.5. Security¶
Security is equally as important as interoperability within the GEISA specification. All protocols included in the GEISA specification support robust security. Security details and requirements are provided throughout the specification. At every level, from minimizing the attack space, to hardening of the APIs and all services, GEISA security is foundational.
