GSC Engineering, Inc.

Specialists in inter-disciplinary engineering design and troubleshooting

SCIENTIFIC/ENGINEERING COMPUTATION and AUTOMATION

Topics on this page:
SCIENTIFIC & ENGINEERING COMPUTATION
AUTOMATION
HOW NOT TO DESIGN A SYSTEM
DESIGN METHODOLOGIES
THE FOUR-PART DESIGN METHOD
VAX/VMS and ALPHA/OPENVMS SERVICES

GSC is not an IT consulting firm. GSC focuses on:

  • Scientific/Engineering Computation
  • Automation
 


SCIENTIFIC & ENGINEERING COMPUTATION

Applications developed have include:

  • Graphics packages
  • Computer-Aided Drafting (CAD)
  • Computer-Aided Engineering (CAE)
  • structural CAD/CAE Software
  • Finite-Element Software
  • Forensic Identification System
  • Mapping Software
  • GPS/DGPS Positioning
  • Image processing
  • Geographic Information Systems (GIS)
  • Air traffic, maritime, & navigation
  • Transportation Planning
  • Solar Shadow software
  • Spreadsheet software
  • Encryption systems
  • JPEG Image analysis software
  • Data (electrophoresis) Filtering Software
  • Lab Automation - LIMS & Chromatography

Typical computation issues GSC considers:

  • Development of new algorithms
  • Data reduction and analysis
  • Optimized computational efficiency (e.g. pre-scaled integer math)

GSC can also help you organize the operational aspects of projects:

  • Requirements Definition.
  • Validation.
 
Return to Top

 

 

AUTOMATION

GSC projects have included:

  • Pharmaceutical Manufacturing
  • Electronics Manufacturing Burn-in
  • Electromechanical Controls
  • Computerized Controls / SCADA
  • Embedded & Real-Time Systems
  • Hardware Manufacturing
  • Network & LAN wiring

Not all of the automation that GSC does involves computers. However, typical computer automation issues GSC considers:

  • Real-Time response
  • Robust design (boundary conditions, handling special cases or designing them out of the system)
  • Data-acquisition hardware / software issues (e.g. SNR, time constants)

GSC can also help you organize the operational aspects of projects:

  • Project Management
  • Requirements Definition.
  • Operational Procedures.
  • Validation.
  • Team building & training permanent staff - not just a course - GSC can actually set up an organization and turn it over to you for long-term operation.

GSC can apply broad inter-disciplinary engineering experience to troubleshooting problems in the application domain. If a system is broken, or is not working optimally, GSC can help.

 
Return to Top

 

 


HOW NOT TO DESIGN A SYSTEM

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.

The Problem with Requirements

Are User/Functional "Requirements" bad? Not necessarily. But a focus on Requirements 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.

 
Return to Top

 

 


DESIGN METHODOLOGIES

GSC has a proprietary development methodology (the "Four Part Method") that it uses for some, but not necessarily all designs.

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).

 
Return to Top

 

 


THE FOUR-PART DESIGN METHOD

This methodology brings proven techniques of hardware design and/or building construction design to computer systems and software.

While content is always more important than form, experience has shown that certain layouts improve the utility of documents. Examples: Putting a cover page on each document separates finished designs from rough ideas. Each design is normally published as a separate document and tracked individually. The location of information on authors. This should never go on the front cover. Instead it goes on a Revision History page in the 'front matter'. This explains who changed what, and when; and more importantly who is responsible for what. A junior staff member can make a minor revision and get appropriate credit, but a question about basic concepts will still be directed to the original author. This minor detail facilitates an approach whereby the fundamental design concept and general layout are prepared by an experienced senior designer, and the final design is left to an assistant. This is delegation that works!

The four consecutive parts are:

  • Functional Definitions (FUN)
  • Interface Designs (IFD)
  • Transaction Designs (TXD)
  • Code/Module Designs (CMD)

The Functional Definitions explain what the system must accomplish (simply - avoiding detail on how this should be accomplished). Sometimes called 'one-page descriptions', they should be understandable by non-specialists. Groups of related functions can be combined into facilities.

This is the most detail that should be incorporated in a contract. For a validated system these include the formal 'Requirements'.

To make a comparison with building construction, these definitions are equivalent to the 'Architect-Client Agreement' - they establish the scope of the project prior to design.

The Interface Designs show how the system interacts with the outside world - this may consist of an interactive user interface, calling sequences, file formats, or hardware pinouts, as needed.

These features must be designed, and the time needed to do this may be a major part of the development cycle. The interface often needs to change or evolve during the project. The traditional 'Functional Spec' that tries to treat the interface as a fixed arbitrary a-priori decision usually fails.

In the construction analogy these would be the architectural drawings - they describe how the building appears from the outside or to the occupants, but not how it works.

The Transaction Designs explain how the system is supposed to work. These are by far the most important designs and unfortunately also the most neglected aspect of design.

This is where the designer explains why he/she thinks the system will work. These designs cover the physical and technical answers to the problem at hand. They describe the special cases and boundary conditions and how are they handled. If a design can't be convincingly explained on paper, it is unlikely to work when implemented.

These 'internal designs' were initially used for database transactions, hence their name. In the construction analogy these would be the engineering designs/drawings - e.g. structural, HVAC, electrical, - they describe how the building works and why it doesn't fall down.

The Code/Module Designs show how the logic is distributed into source modules and files. These determine whether certain code is shared or duplicated. These designs describe specific naming conventions. Here is where libraries and build procedures are planned.

In the construction analogy these would be the 'shop drawings' - detailed drawings of individual pieces of steel or equipment so they can be prepared for assembly.

 
Return to Top

 

 


VAX/VMS & ALPHA/OPENVMS SERVICES

"It's NOT a legacy system, it's VMS"

The VAX and Alpha, and VMS/OpenVMS have fallen out of fashion in recent years, but are still used for high-reliability scientific and control applications where uptimes are measured in years. GSC still provides services for these systems.

(VAX, Alpha, VMS, OpenVMS, and DECnet are trademarks of Hewlett-Packard)

 
Return to Top

 

GSC ENGINEERING, INC.TM - 298 Prospect Street - P.O. Box 269 - Stoughton, MA 02072-0269 - voice: (781) 344-0087 - fax (781) 344-2012

Click here to send email to GSC