Designing an architecture platform for scalable system integration applications is complex. Through years of dedicated research ST Software understands the intricate development constraints and challenges that such a solution comprises of.

Herewith are some common questions and statements:

Third-Party integration offers risk of instability and memory leaks

It is true that direct Win32 integration offers risk of memory leakage and instability. On the other hand, programmers and third-party developers require flexibility. Our approach in solving this is to:

  • Provide a framework for direct integration via .NET (Managed) and Win32 (Unmanaged) methods.
  • Provide a framework for integration via TCP/IP or Web Services.

I am not a programmer, PSIM software is too complex to configure

We cater for both programmers and non-programmers alike:

  • Programmers can make customisations via C# scripting and HTML.
  • Non-programmers can just configure the “ready to go” smart code – no scripting required. This works especially well in niche market type industries with pre-configured templates and rules.

Editing and configuration of a large site can be very time consuming

Yes, the platform deals with bulk site configuration and the data capturing process in a centralised and efficient manner.

Do I need to purchase additional licenses for logging or reporting functionality?

No – Centralised logging and reporting (with default templates) is included as standard.

Too much data is being logged

This seemingly simple issue is indeed very complex. Do you log on change? Yes. Well – how does logging behave on system start up? (This is just one of the many questions on the subject) Default configuration of “smart filters” and data persistence controls the logging behaviour within PSITECH™. The default configuration can be customised to allow for exceptions.

Keeping backwards compatibility with third-party code

This is a complex issue. We have seen major changes in the software world – from 32-bit to 64-bit architectures, the introduction of .NET, the introduction of many “vendor specific” software technologies, the emerging web technologies and various changes within the mobile space. Our interfaces are designed in such a manner to allow maximum protection and consistency from internal and other “vendor specific” technology changes.

I want a report of my “live system status” directly from SQL

Yes, this is possible - “out of the box”, with the applicable buffering to ensure a smooth operation.

Logging must work even if communication to the server is down

Yes, it is locally buffered and synchronised.

The specific alarm is a pulse that disappears very quickly

Such is an example of an alarm that should be latched. Default “smart templates” will determine the most suitable data settings per object type. All settings can be altered to cater for exceptions.

I have a piece of equipment with a combination of states

Yes, the data model caters especially well with the representation of “complex equipment” and the grouping of associated states. This is especially important in order to display and log relevant data and for the quality of reporting.

Allow third-party users to build a reusable template library

Yes, this is a standard feature of the software. Niche market solution providers can build and customise their own reusable template library or just use the standard one available.

Building customised reports with filters for user input

Yes, this is available as a standard feature. The reporting server allows for centralised management and configuration of the entire reporting function.

I want to display the graphical user interface on a very large screen

This is no problem – the Scalable Vector Graphic format is ideal for zooming out without any loss of graphical quality.