Today’s enterprise article focuses on a long-running Windows development large-scale project brought to us by Didier Cabalé. Didier describes “SCULi” which forms the backbone of diagnosing maintenance issues for Liebherr’s extensive range of products used in the construction, maritime, and mining industries. SCULi is entirely written in Delphi and began life 17 years ago and has successfully journeyed through various changes in Windows operating system and the evolution of RAD Studio itself. This is what Delph does – runs well, and keeps on running silently, rock solid and reliable – virtually nothing else can make that claim. There are over 6000 internal and external Liebherr users using SCULi every single day.

What is the SCULi enterprise development?

“SCULI” is an abbreviation for the “Service Client Universal” that is used within Development, Production and Service of various Liebherr products for construction machines, maritime cranes, mining. This system permits the diagnosis and execution of regular service maintenances on the Liebherr electronic devices or ECU’s (Electronic Control Unit).

Sculi is not only a “simple” diagnosis tool, but also an integration system in which various services can be offered. Those services, that can be functions or communication protocols, are integrated through the so-called extensions.

What are the functions of SCULI?

The various functions are as follows (not exhaustively listed):

– For the Engine:

Other SCULI enterprise development dashboards

• Pump codes (not shown)
• Error memory
• Cylinder cut-off

• Click test (not shown)
• Bleeding
• Compression test
• DPF filter maintenance
• Dozens of graphical Tools that represent the overall engine schema with their related key-variables.

For the Engine and the Machine controllers

For the machine controllers.

• Module info (not shown)
• File transfer
• Monitor emulator

“Extensions” are the libraries that are part of the SCULi program and refer to functional bricks. They are handling:

• specific connection to “engine” type controllers
• specific connection to “machine” type controllers
• Messages extracted from the controller
• Messages database retrieval and presentation
• controller’s specific interface and monitor
• the program’s resources, like pictures
• application’s Framework
• the Liuid, the home-made identification system for any machine or engine.
• the application’s Events broker.

SCULi is used by over 6000 internal and external Liebherr users world-wide.

It allows On-board and remote control.

What is the SCULi enterprise development architecture?

The target system is from Windows 7 to Windows 11.

The licensing system was formerly based on a configurable Marx dongle. It is now based on a proprietary access management system that requires a hardware dongle for certificate storage and a license file. The resulting license system enables or not the functionalities depending on the user’s level for targeted ECU’s identifier pattern (LiUIP).

How does Microsoft COM play its part in the SCULi enterprise development?

COM architecture permits to decouple the extensions from the main application back-bone. This has some advantages:

• Enable a distributed development, among several Liebherr subsidiaries.

• Enables integration tests
• Enables us to command SCULi with scripts

How did you integrate COM with Delphi?

Delphi provides a .tlb file editor:

…and transforms it to a *TLB.pas Interface source file, used overall in the project.

How does SCULi communicate with the ECU hardware?

Before 2014, the communication layer between SCULi and the ECU’s was part of the framework extension. According the type of the ECU, different communication protocols had to be used.

Since 2014, the communication with the ECU’s has been delegated to an external specialized layer, MCom.

• Logging and Error tracking system: SmartInspect and EurekaLog
• Translation: POEdit and DXGetText.
• Setup: build with Inno Setup
• Project volume: ~1000 unit files.

Why did you choose Delphi for SCULi?

The SCULi project started in 2006. At that time Delphi had been estimated as the best candidate for building robust and fast Win32 applications.
Delphi was also, at that time, the best candidate to develop against the COM based architecture we want to follow.

In addition it offered a wide range of third-party libraries that covered all of the functional spectrum. In 2009, the whole project has been migrated to Delphi 2009.

What third-party libraries did you use?

We used the following third-party libraries

• DCPCrypt2
• DISQLite3
• GDIPlus
• Indy10
• JCL + JVCL
• Python for Delphi
• RE (Regular Expression)
• TeeChart-Pro
• TMS
• TurboPower
• Virtual TreeView
• wPDF
• XML Parser (from destructor.de)

What other things should we know about the SCULi enterprise development project?

Today, in 2023, 17 years after its start, Delphi keeps getting its incomparable advantage over the other development tools in the market for building Win32 application, due to its high compactness /speed of the resulting binaries together with a flexible + powerful toolbox component set. Migrating from Delphi 2009 to the next Delphi versions could have even improved the developer’s productivity (lot of language enhancements) and overpass the limit of developing only for Win32 platforms (Android, Linux, Mac-OS, iOS).

---

This article was submitted as part of our Enterprise Article Showcase. If you have a success story to tell about a project which makes use of RAD Studio with Delphi or C++ Builder, or any of our other great enterprise products please get in touch. Read all about it here: Enterprise Article Showcase