List of public pages created with Protopage

Untitled 8

Rich sticky notes

Early History

1985-1989 : Adoption of technologies to allow autonomous firmware control of Loral's commercial satellite
    o hardware electronics needed to migrate to firmware
    o IO migrated from a central processor to a set of dedicated IO processors
    o Rad hardness dictated 1553 bus to communicate with the IO processors
    o Rad hardness dictated 1750 processor
    o 1750 processor dictated either assembly, Ada, or Jovial

1990- Intelsat 7 was first satellite to fly with above technologies
    o Home-grown Marconi 1750 processer as Central Processor (with 1 spare backup)
    o RAM was not RAD hard, all critical variables had to be 2/3 voted
    o 62.5 ms cycle was our basic control cycle, all applications were scheduled to run within this cycle. Overruns were not allowed and worst case timings were carefully tested.
    o Firmware executed from 64K PROM
    o Firmware written in 1983 Ada and 1750 Assembler.
    o IO processors has 16K PROM/RAM and used Texas Instruments processor
    o Mission life about 10 years, patch capability was important and heavily used.

1992-2000 Firmware migrated to 1750 IBM/Federal Systems
    o 1750 Central Processor  written in Ada/Assembler
    o Firmware stored in 128k PROM, but executed from 128k Rad-Hard RAM
    o 30+ satellites were flown
    o 1553 bus to communicate with TI IO processors
    o 62.5 ms was divided into 8 subcycles for antenna tracking
    o Patching on almost satellites was required.

2001-Present
    o 1750  Central Processor approach was split into two 1750 processors
          o 1 for Data handling - Rate Monotonic Scheduler
          o 1 for Attitude control- Fixed Subcycle Scheduler
    o 1553 was used to talk between processors
    o 1750 Ada/Assembler for the dual processors
     o Auxiliary 1750 processors were developed on some satellites to reduce loading. Firmware
          written in "C" on these processors.

Future
    o replace 1750 with PowerPC 750
    o Port Ada to 750 whenever possible, use C for new development.

Some Talk Ideas for Sean

Below are some sticky notes to help in developing a talk

Ada: Pros and Cons

Pros:
    o Good maintenance record (15 years of changes by many programmers).
    o Strong typing and Ada compilations eliminated many errors
    o Ada allow good modularity. Each module (set of packages) could be modified
          be an engineer without effecting other engineers.
    o Once indoctrinated to Ada, most programmers were committed to Ada resulting
          in a relatively low turnover rate even when most of the code was maintenance.

Cons:
    o Hard to find Ada programmers.
    o Most programmers prefer and perceive  "C", Java, Perl as future while Ada
          is "old"
    o C has richer set of tools for development.

Operational failure cannot be tolerated

A commerical satelite will produce $billions of revenue each year. An out of control rotating satellite will lose lock with ground and be a major failure event for TV and phone service. Firmware must be designed to avoid loss of lock.

Firmware executes in a harsh environment
    o Cosmic radiation can adversely firmware control. SEU can cause Memory bits to flip.
    o Sensors, commanding and telemertering units can be fail

Firmware must handle all adversities!
    o All units must have backups and be switched w/o loss of lock
    o Backup control processor must come on-line with current attitude state and immediately begin controlling the satellite using appropriate IO devices.
    o Memory must be protected against SE upsets by correcting single bit hits.
    o Firmware must autonomously detect equipment failures and perform corrective actions.
    o If possible firmware patches can be uploaded to handle permanent hardware failures.
    o Give some examples we have seen during the last 20 years. Several programmers are
          working full-time developing patches on many satellites currently in orbit.
    o Ground must be supplied with sufficient information to isolate cause of failure and develop
          patches.
    o Normal TLM, Dwell TLM and Memory readout are used to send detect failures


Process used to avoid Ad Hoc Development

Each new Satellite used a baselined version from a previous satellited.
All changes for new satellite had to tracked.
    o Software Problem Reports were used to instigate new changes.
    o No software changes could be done without an approved SPCR.
    o Peer review reqired to verify that changes correctly solved the SPCR and didn't have any adverse
         affects.
   o SPCRs and baselines were maintained for the life of the satellite (10-15 years). Patches
       required good record keeping.

Software Reuse is Critical!

Ada was helpful for reusing software components.
    o Firmware was composed 250 Ada packages(modules)
    o Most of the 250 packages survived 15 years of maintanence w/o complete rewrite.
    o Many packages had up to 10 programmers maintaining the code for the 15 years
    o Each satellite used the original 250 packages with only a few changes to meet new mission
          requirements.
    o Ada Compiler was good at catching most bugs.

Unit and Integration testing was also very important
    o Each satellite build was completely tested in both a simulated mode, and with open loop
          close loop tests using live hardware.
    o Team of test engineers used in conjunction with unit tests performed by the firmware staff
    o Testing occurred at many phases
          o Unit testing using Ada simulator and test scripts and/or test drivers
          o Integration testing was done at special hardware 3-axis lab
          o Final testing was done at satellite test facility for many months.
 


Firmware, deterministic and optimized

Firmware was written in a deterministic way.
    o  No concurrency- race conditions, deadlocks and ambiguities had to be avoided.
    o  No third party hidden code. All Application and OS source were open and understood by
          firmware engineers.
    o  On-orbit debugging was difficult and required source code to be carefully written with the
          idea that debugging would be done 30,000 miles away.
    o Debugging consisted of examining telemetry and memory readout.

Optimization
-----------------
    o 1750 was performance was comparable to 1984 IBM/AT
    o Firmware used upto 89% cycle capacity after many optimization techniques were applied
    o Typical opitimization techniques:
          o No extra procedural layers. Structures were accessed directly, not through proc calls.
          o No run-time checking:
          o Minimal type conversions were done, mostly structures were converted to other
                structures without type checking.
          o No excessive copying was done. Ptrs were used and copied instead of data structures.
          o No exceptional handling done at language level. Exceptions causing interrupts would
             be handled by interrupt handlers.
          o Each routine was analysed and hand coded for best optimzation. Compiler would optimize
                 at  the instruction level.

No overruns were ever detected during 15 years and 30 satellites.


      

Untitled 12

Rich sticky notes

Saga- Internet via usb

Use ActiveSync to "pass through" this computer. That means the connected device can use the computer's network connection as if it were its own. You can use this feature to perform tasks such as downloading non-Outlook e-mail messages, to connect directly with Exchange Server, or to browse the Internet.



o So I should be able to use ActiveSync to browse the internet!

Saga- ActiveSync

Can't determine if this is working even though log shows activity.

Saga Wireless

Can't get wireless to work. Won't accept parameters.