CubeServ Blog
Stay up-to-date on the data-driven business with tools for analytics from SAP & Co. and do not miss any news, downloads & events.

The Internet of Things, Big Data and a Fischertechnik Factory – Part 2: Consequences for architecture

In the first part of this blog, I outlined the challenges that big data poses for a data warehouse, which leads to simple conclusions for the big data architecture of such an EDW in the specific case of SAP BW on HANA or SAP BW/4HANA:
  • It is not possible to load all data into SAP HANA. The data volumes are too large, and the HANA hardware is disproportionately expensive for this case. It is advisable to use an appropriately scalable and cost-effective solution for the mass of raw data, e.g. an Apache Hadoop cluster. Such clusters offer scalability over a large mass of inexpensive hardware and already consider the constant failure of individual parts in their architecture. For example, the Hadoop file system HDFS always stores the data multiple times and is therefore ready for operation even if individual servers fail. At the same time, the system must of course take into account that it does not count or deliver the data stored multiple times. Hadoop was designed for this purpose. Smaller extracts or aggregates of these large volumes of data on the Hadoop side can now be loaded into HANA or stored in memory on the Hadoop side, e.g. with the help of the Spark adapter, as used in SAP Vora.
  • Not only data but also events must be orchestrated. The occurrence of certain events in the data (e.g. alarm messages) can trigger certain processes on both the big data side, the Hadoop cluster, and the BW side (reloading data, creating service messages, etc.). These events must be orchestrated on both sides so that processes can be defined across technologies. In addition to managing data transfers, the SAP Data Hub also offers joint management of events, jobs, and triggers.
All these considerations are always quite abstract. CubeServ has therefore acquired a factory simulation from Fischertechnik to build and demonstrate such an architecture in concrete terms. The factory consists of a high-bay warehouse, a central crane, a kiln, and a sorting system. The factory’s goods are white, red, and blue plastic cylinders, which are stored in rectangular black boxes in the high-bay warehouse.
Here is the factory in action:

You are currently viewing a placeholder content from Youtube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.

More Information
Fischertechnik factory simulation 24V in use – for generating big data sensor data
A colored good is taken from the sorting chute for white (where it is incorrectly located), taken by the crane to the kiln, from there to the sorting belt, and then sorted into the correct chute.

The individual areas are controlled separately, but a complete cycle can look like this: a product is removed from the high rack, and the central crane takes it to the kiln, where it is processed (symbolized by flashing lights). From the kiln it goes to the sorting system, a photocell recognizes the color and it is sorted into one of three chutes accordingly. From there, it is removed by crane and taken to the high rack, where it is sorted again. Some of the individual areas are equipped with sensors such as light barriers or photocells for color recognition and motors.

Here is the link to the product homepage of this factory:

The factory is delivered fully assembled, but without control units and therefore without the corresponding programming. To control the factory, eight Siemens Logo 8 control units were connected to the corresponding sensors and motors. The control in the Logo language was then carried out by our basic expert, Peter Straub. This programming is quite complex, the language and factory components provided are very simple. There are only a few sensors. If, for example, the central crane is to be turned to the home position, it is simply turned in a certain direction for a certain time. As it cannot turn beyond a fixed stop, it is therefore in the 0 position. The components of the LOGO language are also very elementary (AND gates, OR gates, time delay, and the like). For example, there are no convenient variables that could be used for stock management. The wiring of the devices and the programming of the factory took about four weeks.

The next part of the blog will then deal with how data from this factory is now transferred to a big data cluster.

Subscribe our Newsletter

Keep up to date on SAP Analytics Cloud, SAP Data Hub, and Big Data, and do not miss any news, downloads & events.

Expert Team