Functionality and philosophy of the Run-time system

The heart of iPlus-framework is an object-oriented, component-based framework that is based on the Microsoft® .NET framework. The system is fully service-oriented. This means that all classes or components are only brought to life by configuration in the database. All instances can communicate with each other in a network-transparent manner. The programming of the components is also network-transparent. This results in a limitless scalability of the system and multitier architectures can be set up at the click of a mouse. In addition, the system is completely event-driven to enable process processing and visualization that is almost real-time.

Due to the service-oriented architecture, different manufacturers can develop their own solutions, which later run together on a target system without the need to compile an overall system. It is comparable to a conventional package management system such as NuGet, but with the main differences that

• the software components do not have to be linked together by a final compilation,
• that a software package can only be declarative (no .NET assemblies, only project configuration files and GUI description in XAML),
• the packages can be added during runtime (e.g. in a production system).

This has the following advantages:

• Different parties (project engineers, consultants, developers, teams) can work independently of one another on an overall solution.
• For time-critical systems, the overall solution can sometimes even be expanded during productive operation. If a suitable time window is then available, the iPlus services can be restarted with the fully configured setting.
• Integrated change request management: configurations that have been created on test systems (local computer, shared test system ...) can be transferred to the productive system via export / import.

Explanation and classification of IPlus using the software and .NET assemblies

iPlus-framework is developed with Visual Studio and is based on the .NET framework 4.8:

iPlus-framework can be used or licensed either independently or with MES functionality. For standalone use of iPlus, the minimum configuration is assemblies 1,2,3,5 (optional 4). Additional 5.6.7 (optional 4) assemblies are required for MES functionality.

In concrete terms, these are

iPlus standalone:

gip.core.datamodel
gip.core.autocomponent
gip.core.layoutengine
gip.core.dbsyncer
gip.core.ControlScriptSync
gip.core.manager
gip.core.processapplication
gip.core.reporthandler
gip.core.archiver
gip.core.communication
gip.core.visualcontrols
gip.bso.iplus
gip.iplus.client
gip.iplus.console
gip.iplus.service
gip.iplus.startup
gip.tool.installerAndUpdater
gip.ext.chart
gip.ext.design
gip.ext.designer
gip.ext.editor
gip.ext.essentcollections
gip.ext.essentinterop
gip.ext.fluent
gip.ext.graphics
gip.ext.modbus
gip.ext.opctoolbox
gip.ext.widgets
gip.ext.xamldom
gip.core.scichart
gip.bso.twincat3
gip.bso.tcStudio
gip.core.tcAgent
gip.core.tcClient
gip.core.tcShared

Additionally for iPlus-MES:
gip.mes.datamodel
gip.mes.autocomponent
gip.mes.manager
gip.mes.facility
gip.mes.maintenance
gip.mes.processapplication
gip.mes.archiver
gip.bso.facility
gip.bso.licence
gip.bso.logistics
gip.bso.manufacturing
gip.bso.masterdata
gip.bso.purchasing
gip.bso.sales
gip.core.processfacility
gip2006.core.processapplication
tcat.variobatch.processapplication

All assemblies are dynamically loaded by the iPlus framework, and the classes and components based on the iPlus framework are instantiated by reflection. In order for this to work, these assemblies have to correspond to a certain name scheme (see Asterisk image above). This requires, if you want to build your own Assembly, which is based on the iPlus framework you have to adapt to the naming convention. Apply the following rules:

Part 1 of the file name corresponds to your company name.

Part 2 of the file informs about the classification of the abstraction level.

• "core" = core component, abstraction level
• "mes" = core component for MES, abstraction level 1
• "bso" = contains business objects, abstraction level 2
• "solution" = contains components for customer-specific solutions, abstraction level 3

Part 3 of the file name is freely assignable. Use a name that is as concise as possible.

The gip.core.datamodel.dll-Assembly (1)

The gip.core.datamodel.dll assembly is based on the entity framework to provide access to the database.

In the database

• the metadata of all classes/components (properties, methods, designs,...)
• the project configuration of the customer solution (instances, hierarchies, relations,...)
• users, groups, rights, languages, alarms, logs...

stored.

This information can be queried and changed via helper classes/methods. The gip.core.datamodel is similar to the type and reflection system of .NET, but with the difference that is done using a database. This is necessary for object-oriented programming with the iPlus development environment without new. NET types or assemblies.

Other tasks of the gip.core.datamodel are:

• Define abstraction base, so that presentation and object models are completely independent of each other. The interfaces and abstract classes which are defined here, are implemented the gip.core.layoutengine (Presentationlayer) and in gip.core.autocomponent (model and logic).
• Provides serialization and deserialization
• Generation and persisting of dynamic LINQ and/or EntitySQL expressions.
• Multi-Threading tools (delegate-queues, locks, deadlock hierarchies for preventive deadlock avoidance)
• Instantiation, caching, pooling, and garbage collection of automation components
• Licensing Tools

The gip.core.autocomponent-Assembly (2)

The gip.core.autocomponent assembly implements the abstract definitions from the gip.core.datamodel. It is the base assembly, on which build all other assemblies that contain model classes (but no presentation). The name "autocomponent" is an abbreviation for "Automation-component" which is the base class for all classes that are later instantiated and managed by the iPlus runtime.

The base class "ACComponent" performs the following tasks:

• Lifecycle management for initialization and deinitialization phases, iPlus garbage, and pooling
• Network transparent communication for synchronous and asynchronous method calls, property values, properties-binding, references to other ACComponents and entity objects
• Recursive parent/child model in the ACComponents organized in tree structure and can comunicate mutally
• "Virtual" inheritance mechanisms (extension of ACComponents by C# scripts, properties, configuration values...)
• URL-based command interpreter (similar to REST)
• Diagnostics and debugging

ACComponent is similar to the "System.Object" class in the. NET Framework. All other classes inherit from it. If you want to build your own industry-specific Assembly, you should derive from ACComponent.

Additional functionality of the gip.core.autocomponent Assembly:

• Alarm handling and logging
• Workflow management: Method programming using program flow diagrams
• Update management (class analysis by attribute of classes and reflection, database model update, designs update)

The gip.core.layoutengine-Assembly (3)

The presentation is done using WPF/XAML. In typically WPF applications, surfaces compiled as BAML resources in the appropriate assembly. iPlus is going another way: all designs are stored in the database as XAML. As soon as a ACComponent is to be presented, the XAML code is loaded from the database and compiled just-in-time by the XAML parser and presented by the iPlus framework. This is the most important task of the gip.core.layoutengine.

The database-based approach has the advantage that the entire interface can be customized without losing the update capability. In addition, the database-based approach is necessary since iPlus is also a SCADA system.

Other tasks of the gip.core.layoutengine are:

• Encapsulation of the powerful WPF binding mechanism through simplified VBContent and ACURL syntax.
• Loose binding to ACComponent-proxy instances and their release for the garbage collector
• Built-in WYSIWYG designer with XAML switching (supports styles, data and property trigger, expressions, multibinding)
• Rich control Library with theme switching
• Converter
• Drag-and-drop support

Use your own controls

If you want to develop your own controls, you should set up on the gip.core.layoutengine. Name your assembly according to the naming conventions and use "controls" as Postfix. An example of this is the gip.core.visualcontrols.dll. It includes control elements for automation technology.

Class libraries to extend the development environment or application functionality

Assemblies that include the word "manager" usually contains components which serve to enhance the functionality of the development environment or business objects. Business objects are automation components that appear on the surface and working with application tables (E.g. material management, bin location management, delivery notes,... but also the iPlus development environment itself). If you need to have common functions that are required by the business objects, but also in the background of server-side instances, you should outsource these functions to so-called "manager" assemblies so that you may avoid circular Dependencies. Examples of this are the gip.core.manager.dll (iPlus) and the gip.mes.manager.dll (.MES). 

The gip.mes.datamodel.dll-Assenbly (6)

The gip.mes.datamodel assembly contains the data model for MES functionality. In this case you also need the extended database with the MES-relevant tables. There are two different database files:

1. The pure iPlus database contains only the tables that are necessary for the iPlus runtime.
2. An extended IPlus database with additional application tables for the MES system.

The gip.mes.datamodel assembly also doesn't extend the Entity Framework model (.edmx) from the gip.core.datamodel. It is a completely separate and must be opened in a separate database context (System. Data. Objects. ObjectContext).

In the database model, foreign key relationships are also one-way. MES - relevant tables can refer to iPlus - relevant tables but not in the other way.

In later programming, you can use helper functions that make it easier to match between these two database contexts (see EntityObjectExtension).

Of course you can also add your own application tables to the iPlus database model and create your own .datamodel assembly. You must implement the interface IACEntityObjectContext and use the class ACObjectContextHelper. See the topic "Add application tables".

Class libraries for application programming.

Assemblies that are required for the actual application or industry solution should conform to the following naming scheme:

• *.bso.*.dll: The Assembly contains mostly automation components that are business objects (BSO).
• *.solution.*.dll: The assembly contains various automation components (server-side and BSO's) and is intended for a customer solution or industry solution.
• *.mes.*.dll: The assembly contains various automation components and is a part or an extension for iPlus-MES