Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

BaSyx / Documentation / ControlComponent

< BaSyx ‎ | Documentation
Revision as of 10:20, 12 March 2020 by Daniel.Espen.iese.fraunhofer.de (Talk | contribs) (Updates top links)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Overview | Interface | Implementation

BaSys 4.0 control and group components

The Device Layer of a Basys4.0 compliant production systems contains Control Components and Group Components, which reflect the new skill-based and hierarchical programming approach of such a system. A Control Component represents the lowest layer of the plant and directly connects to the controlled process via an Input/Output (IO) interface and a network interface to the Group Components on the next hierarchical layer. Group Components are typically not directly wired to the physical process under control. Instead, they serve as orchestrators for the Control Components and provide a network interface to the underlying Control Components and another network interface for the connection to other Group Components and the Basys4.0 compliant Middleware.

BaSys 4.0 control component

Control Components are typically programmed via standardized PLC programming paradigms. The two fundamentally different approaches are the cyclic execution model of Function Blocks (FB) of the IEC61131-3 and the event-based execution of FBs according to IEC61499. IEC61131-3 defines five languages for programming PLCs and its standardization was first published in December 1993 (the most recent standard was published in February 2013). 3S is for example implementing an IEC61131-3 development and runtime environment called CodeSys. The standardization of IEC61499 started after the standardization of IEC61131, by the same standardization group, which previously worked on IEC61131 with the main objectives of solving portability, configurability and interoperability for industrial control applications that IEC61131 does not solve. The most recent version of the IEC61499 standard was published in November 2012. The standardization group added events to the interface of the FBs and therefore changed the execution semantics. IEC61499 targets distributed industrial automation systems in contrast to IEC61131, which is focused on centralized systems. Eclipse 4diac is an open-source implementation of an IEC61499 compliant development and runtime environment.

A Basys4.0 Control Component's IO interface connects the device to the sensors and actuators of the process in the field level. These IOs are digital or analog signals which are treated differently by each device manufacturer. Therefore, porting an existing runtime environment to a new PLC usually includes the adaptation of the runtime to the IO interface of the device. The connection to the next hierarchical layer (the Group Components still on the Device Level, or the different components in the Basys4.0 Middleware) is achieved by a network interface. Here, BaSyx proposes to use standardized network protocols as http/Rest or OPC UA. However there exist plenty of different proprietary network protocols and fieldbusses in state-of-the-art production systems. Usually each of the big market players provide their own fieldbus which cannot interact out of the box with fieldbusses of other manufacturers. This lack of interoperability can be tackled using BaSyx, which provides the possibility to introduce gateways from any kind of protocol to the afore mentioned standardized protocols on which BaSyx usually operates.

Examples for control components could for example be vertical and horizontal axis' that provide the basic skill "go-to-position" or a gripper that offers the basic skill "grip". These separate skills are then advertised via the network interface to Group Components and the Middleware.

BaSys 4.0 group component

BaSys4.0 compliant Group Components significantly differ from Control Components because they do not have an IO interface to the process under control, but rather two network interfaces, one to the underlying Control Component(s) and one for connecting to other Group Components or the services in the BaSys4.0 Middleware. The function of such a component is not to directly interact with the process, but to coordinate and orchestrate the Control Components, which are then interacting with the process. Therefore, a Group Component combines the different basic skills into composed skills and advertises these composed skills via OPC UA to upper layer Group Components or the Middleware. An example composed skill of an orchestrating Group Component of the Pick&Place station would be "assemble", which combines the basic skills "go-to-position" and "grip" in the appropriate order such that it achieves the desired task of assembling a product.

Back to the top