GSC is NOT an Information Technology (IT) company.

GSC does assist computer and software developers and IT departments with:

• Scientific computation
• Engineering computation
• Automation
• Sensor wiring & networks

GSC helps you ensure that the science and engineering incorporated in algorithms and hardware matches the behavior of the actual system.

Building and machinery commissioning involves more than computer validation and commissioning. The computer may be happy but the machinery may be very unhappy. Engineers were commissioning things long before computers (USS CONSTITUTION was commissioned as it went through sea trials in 1798). We don't just detect problems, we fix the problems detected during integration and commissioning.

GSC does continue to support legacy software clients. We never let them down.

Although software development is no longer GSC's primary focus it is part of our proud history. Many of the following were advanced state-of-the art developments and some were pioneering efforts in various industries.

In a recent disaster movie the rescue ship was nearly destroyed because the computer would not let them start the engines until all the hatches were locked. This is not "fail safe" design. This is more like chaining the fire exits closed. It is essential that logic like this be excluded from critical systems.

Methodologies

Trying to focus all design issues into one method is like trying to use the same calculations (*) to determine the stability the stability of a building and the arc-flash hazard of an electrical panel - it won't work!
There are many useful methods and tools. But they must be appropriate to the problem at hand. Many of the best are based on classic engineering theorems. One of the earliest was the Data Flow method - it is essentially the same as Mass Flow or Heat Balance in Civil or Mechanical engineering, and when data is 'flowing' it is still a useful check.
(* = however interdisciplinary engineers know that Prof. Hardy Cross developed calculation methods for both of these, and other, fields - all engineering can benefit from understanding other disciplines).

Requirements

Are User/Functional "Requirements" bad? Not necessarily. Alternatively should you use "Agile" methods (start building and figure out along the way)? A focus on either of these approaches frequently leads to neglect of careful internal architecture. It is essential that a system be 'internally consistent'. Otherwise gaps will exist in the internal logic. Nature will find these gaps, just as the ocean will find any leaks in a ship. For example: traditional discrete controls were designed such that a short or broken wire would cause a motor to fail 'safely' (usually to stop) and not run wild uncontrollably. This is why so many catastrophic failures occur in systems that have successfully passed validation tests. These gaps can only be eliminated by careful internal engineering design.

Flyer about Protecting Good Science from the Wrong Automation (PDF)