GSC Engineering

Specialists in inter-disciplinary engineering design and troubleshooting

GSC designs systems and develops software for a wide variety of platforms, operating systems, programming languages, and applications.

GSC focuses on:

• Scientific, engineering, technical & embedded applications.

GSC projects have included:

• Development of products (hardware & software)


• Internal projects (e.g. custom systems or installation/integration)

Typical issues GSC considers:

• robust design (boundary conditions, handling special cases or designing them out of the system)
  
• optimized computational efficiency (e.g. pre-scaled integer math)
  
• data-acquisition hardware / software issues (e.g. SNR, time constants)
  
• transportable file formats
  
• hardware selection
  
• software development (CASE) methodology - not just colorful binders that sit on a shelf - methods that actually work and that people enjoy using.

Industry experience includes:

• pharmaceutical
  
• food
  
• forensic
  
• electronic manufacturing
  
• software manufacturing
  
• image processing
  
• cartography and GIS
  
• structural CAD/CAE
  
• air traffic, maritime, & navigation

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

• Project Management


• Requirements definition.


• Operational procedures.


• Validation.


• Coordinating contractors.
  
• 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.

This methodology brings proven techniques of hardware design and/or building construction design to computer systems and software.
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. However, for a very simple case, the designs may be combined.
While content is always more important than form, experience has shown that certain layouts improve the utility of documents. Example: 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.

The VAX and Alpha, and VMS/OpenVMS are still used for high-reliability scientific and control applications where uptimes are measured in years. GSC still provides services for these systems:

• VMS 3.0 through 7.2
• DCL programming and procedures. DCL is one of the few job-control scripting tools that provides full programming language features and thus supports powerful procedures.
• Access Control List (ACL) design.
• Device Drivers.
• Advanced Condition Handling and proper stack unwinding.
• Lock Management Facility - as both a sharing and/or synchronizing mechanism and for interprocess communication.
• Dynamic Storage.
• AST programming threads for asynchronous applications.
• Languages including C, FORTRAN, BLISS, FDML, and MACRO-32.
• The DEC FORTRAN optimizing compiler produced some of the most efficient code anywhere. A variant of this compiler exists for the Visual Development environment on PC's. GSC continues to use this for scientific applications.
• MACRO-32 as a high-level language (permits the creation of application-specific macros so that programming can be done in application terms).
• Databases: DBMS-32, RDB, Oracle.
• SysAdmin services: AUTHORIZE to BACKUP to SYSGEN/AUTOGEN.
  
• Shared Global Sections.
  
• Advanced RMS file management.
  
• Procedure Calling Standard (allows procedure calls and the exchange of data between all programming languages).
  
• Logical Name Translation.
  
• Configuration control via CMS.
  
• DECnet and TCP/IP configuration.
  
• TELNET and LPQ/LPS queues/
  
• DEC MMJ hardware adapters.

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