KNOWN HARDWARE

Hardware components

2008-11-15T21:10:00.000-08:00

The current Maxelbot is quite complex when it comes to hardware. Each Maxelbot is equipped with the following components: 1 Lego robot platform equipped with Lego motors, 1 piece of plywood, 3 acoustic transducers, 3 parabolic cones, 2 minidragon microprocessor boards, 1 motor control printed circuit board (PCB), 1 trilateration PCB, and 3 XSRF acoustic sensor PCBs. Each of these components fills a vital role in the overall success of the robot.
First, the robot platform is built short so it has a low center of gravity and it will be more immune to tipping over in rough terrain. We ran into this problem early on in our testing. The trilateration platform, with all the sensors, cones, and electronics on it, was fairly heavy due mainly to the solid aluminum parabolic cones and the robot would tip over if it was on rough terrain or uneven ground. We changed the robot design, giving the robot a low center of gravity and wider wheelbase. This not only made our robots more immune to tipping, but also smaller.
Next, the square plywood board on the robot holds all of the trilateration hardware and connects the trilateration hardware to the robot platform. We have the three acoustic sensor PCBs mounted on the bottom of the plywood to reduce clutter on the top of the board and this also allows us to save space on the top of the board.
The rest of the trilateration hardware is mounted on the top of the board. The board has a parabolic cone mounted on three or its corners. Each of the two outer cones is mounted six inches away from the center cone. When all of the cones are mounted they form a 90 degree angle with a cone on the X axis and one on the Y axis. (*******This sounds bad, not explained very well*******).
1.7 inches above each cone is an acoustic transducer. We ran numerous tests to determine the optimum distance to place the cone above the transducer. We decided on a slightly higher value to optimize the transducer in receive mode and when the transducer is in transmit mode, the distance was slightly shorter, so we split the difference. This acoustic transducer is held in this spot by a piece of PCB which is attached to a piece of allthread by a couple of bolts the allthread is also attached to the plywood board by several bolts. This acoustic transducer is connected to the XSRF acoustic sensor through a twisted wire pair.
Also connected to the top of the board are the two minidragons. Each of these processors also has a PCB plugged in to it. These are also mounted to the top of the plywood board. This board also has a hole drilled in it to allow wires to connect the XSRF sensor to one of the minidragon boards through the trilateration PCB. There are several cables and many wires connecting the minidragon processors together as well as interfacing them with some other components like the acoustic sensor boards.
Next we have the acoustic sensor boards. These boards are a vital part of the trilateration process. These boards do the task of calculating the time it takes between when it receives the RF signal (the lightning) and when the acoustic pulse (the thunder) arrives. These boards send these pulses back to a minidragon where the trilateration calculations are made. Each PCB contains 7 integrated circuit chips: 2 - LMC6032 operational amplifiers, 2 - LP311 comparators, 1 – RS232 chip, 1 – PIC microprocessor, and 1 – MAX362 chip. These boards work in either transmit or receive mode. On the board there is a MAX362 chip that acts as a switch. This control chip along with 2 control lines control whether the sensor is in receive mode or in transmit mode. Transmit mode is easier, so we will explain this mode first. In transmit mode sensor receives a trigger pulse telling the sensor to start. Then the PIC microprocessor generates a 40 kHz signal for 8 pulses. Then this signal is sent to the RS232 chip where it is amplified and sent to the acoustic transducer. This generates our acoustic signal.
Receive mode is slightly more complicated. In receive mode, the trigger tells the sensor to start and the PIC microprocessor drives the echoline or timing pulse high. Then we get the signal in from the transducer and the switch will be in the right mode to route this signal to the receive part of the sensor. The signal first goes through a LMC6032 op amp, which provides two stages of amplification. Each stage will amplify the signal by 18 times. After the signal has been amplified by the first op amp, it goes through another LMC6032 op amp. This op amp provides one additional stage of amplification of 18, but this stage of amplification is also filtered. We use a 40 kHz bandpass filter to eliminate some of the noise in the signal that may have leaked through. This gives us a cleaner signal and better accuracy on our sensor. However, we had a little bit of trouble designing this filter. When we initially designed the filter to pass through 40 kHz; this is because that is the frequency of our signal. This filter was designed, built, and tested and it failed. It was passing through 36 kHz instead. In theory the filter worked, but not in practice. This problem was easily fixed though; we simply adjusted the resistors on the filter until it passed through 40 kHz. By doing this we were able to get the correct passband, but we reduced the gain of the filter from 18 to 15. This reduction is fairly insignificant so we can deal with it. Next the signal is passed to two comparators. Each comparator has a threshold voltage that it compares the voltage of the signal with. This threshold voltage is controlled by a potentiometer. One comparator is set to 2V and the other one is set to -2V. Once the signal coming in to the one of the comparators is greater than 2V or less than -2V, the comparator that saw this voltage will send a signal to the PIC microprocessor telling the processor to stop counting by driving the echoline low. This timing pulse that the PIC generated is sent to the minidragon to perform the trilateration calculations. This will happen for each of the three sensors and the minidragon will receive three pulses to do the trilateration with.
Next, we have the acoustic transducers. These transducers are sensors that are specially tuned to transmit and receive 40 kHz acoustic signals. We simply send the transducer a square wave with a frequency of 40 kHz and the transducer will transmit this signal for as long as the signal is being sent to the transducer. The transducer is also set up to receive a 40 kHz signal and all other frequencies will be ignored.
The parabolic cones also provide an important aspect of the trilateration. The parabolic cones are machined out of aluminum and they serve the purpose of sound distribution. The cones are machined so that when an acoustic signal is aimed at the parabolic cone, the cone will reflect the sound and distribute the signal out 360 degrees in a horizontal plane. This can be done because the cones are cut in the shape of a parabola so wherever the sound signal hits the cone it will be redirected along a horizontal plane. By spreading the signal out in a plane, we do not have to have the transmitting sensor pointing at the receiving sensor. We need two sensors pointed at the parabolic cones that are in the same horizontal plane. Then we can move the transmitting and receiving cones to anywhere in the same horizontal plane and we will still be able to transmit and receive the signal. The parabolic cones distribute the signal through 360 degrees so the power of the signal in the horizontal plane will be reduced. Even with this reduction, the receiver is still able to adequately pick up the signal from the transmitter at 8 feet away.
We also have two minidragon microprocessors on the robot. One of the processors is connected to the XSRF sensor boards and the I2C bus through the trilateration PCB. This processor is responsible for performing all of the trilateration calculations and sending them to the other minidragon microprocessor. The other processor takes these calculations and it uses them to control the motors on the microprocessor. This processor is also connected to the motor control PCB.
The trilateration PCB that is connected to one of the minidragons is populated with the RF transceiver. The minidragon uses the serial communications interface (SCI) to communicate with the RF module. This transceiver emits an RF signal at 315 kHz. This RF module provides the trigger signal (the lighting) for the trilateration process. The trilateration PCB was designed so that the RF module can easily switch between transmit mode and receive mode easily using a control line that we already use for the switch on the sensor boards. This RF module also handles the communication protocol between the robots. This communication protocol will be discussed later. This trilateration board also contains the pull up resistors for the I2C bus and a LED that is controlled by one of the control lines coming from the microprocessor. This LED is lit when the trilateration module is receiving data and it is off when the trilateration module is in transmit mode. The trilateration PCB is an auxiliary board that easily interfaces the sensor boards to the minidragon and provides RF communication between robots. This board has a connector that allows it to plug directly into the minidragon. This is very convenient because it makes the design less fragile and it also eliminates some of the wires.
We had only one minor problem with the trilateration PCB. The problem was that the RF signal coming from the RF module was providing a barely usable signal with lots of errors in it. We experimented with this for a while and noticed that when the minidragon is not connected to the trilateration PCB, the signal is at full strength, but when the minidragon is connected to the trilateration PCB, the signal is compressed and shifted by 2.5V. After some debugging we figured out that the problem was with the minidragon interface to the serial communications interface (SCI). The minidragon was assuming that the incoming signal was at RS232 standard level and not TTL logic levels. For this reason, the signal was getting passed through a RS232 chip and the logic levels were being compressed and shifted. We needed to bypass this RS232 chip and get our signal directly to the SCI receive pin. We were able to accomplish this by simply removing a solder bridge on the minidragon.
The last part of the robot is the motor control board that is connected to the other minidragon. This board also plugs directly in to the minidragon, making the design more durable and eliminating some wires. The motor control PCB is slightly more complicated than the trilateration PCB. This board contains two chips: a 74HC04 hex inverter and a 754410NE quad half Half-H driver. The quad half-H driver takes a supply voltage of 9.6V and it also requires 6 control lines. This chip uses a supply voltage of 9.6V because that is the voltage at which the motors have optimum performance. As for the control lines, 4 of these lines are used to control the direction of the motors. However, we do not actually need 4 control lines from the microprocessor to achieve this task. The quad half-H driver chip requires that it receive a signal and the same signal in quadrature (the opposite signal) for two different signals. This task is easily accomplished by taking only two signals from the minidragon and running them through a 74HC04 inverter. This will give us the four signals that we need; the two original signals and the two converted signals. The other two control lines for the quad half-H driver are to control the speed of the motors. One line is used to control the speed of the left wheel and the other signal controls the speed of the right wheel. We use a PWM signal to accomplish this task. The PWM will generate a square wave with a certain period and duty cycle and send this to the driver chip which in turn controls the motors. The PWM module controls the motor by turning the motor on and off really quickly. However, the motor usually cannot switch the motor on and off fast enough, so the pulse width modulation signal appears to just be providing the motors with a lower voltage and thus slowing down the motors. For example, if a 100% duty cycle is chosen, the motor will run at full speed. But if a 40% duty cycle is chosen, the motor will be on 40% of the time and off the other 60%, therefore the motor will run at 40% of full speed.
The motor control board works great now, but we ran into some problems in designing this PCB. First this PCB was designed to work with another processor board that we have. The female connectors of this PCB mate perfectly with the pins from the other processor. This is not really a problem, but the size and pinout of the PCB could have been optimized for the minidragon processor instead if the board had been designed for that. The next problem is much more significant. When we first designed this PCB, we took the breadboarded circuit and directly put this design on to a PCB and had the PCB fabricated. Then we got the PCB back and populated them. When we tested the PCBs, none of them worked properly. Only one wheel on the robot would work correctly and if both motors were plugged in, neither of the motors would work correctly. After extensive testing and debugging, we found several problems with the PCBs. First, there was no circuit protection on the circuit. We had no bypass capacitors on any supply lines and also unused inputs on the inverter were not terminated. Even without circuit protection, the PCBs would probably have worked, but it is always good to have. The other problem was the major reason that none of the boards worked. This problem was the fact that when we breadboarded up the circuit we used normal solid 24 gauge wire, which can handle more current then we required of the lines. When the PCB was designed, we failed to take into account this fact and the PCBs were designed using the default wires. These wires were not wide enough and what was happening on our PCBs is that the motors required more current then the wires could handle. The wire would then act similar to capacitor and prevent the motors from getting the required current. The PCB was then redesigned to include circuit protection and also the wires were widened to allow more than enough current to pass through to the motors. This PCB design was sent off to be fabricated and when we received the boards back and populated them, they worked very well.
When all these parts are combined together properly, we have produced one Maxelbot.

Telerobot Software

2008-11-15T21:09:00.002-08:00

Description and Reference Information for Telerobot Software in Telelabs

Andrew Babbage's thesis provides useful background information on the development of the telerobot, the various software systems that were developed to provide this world famous internet site, and finally the LabVIEW robot interface routines. In particular chapter 6 provides a detailed account of functions for handling frames and calculating wrist rotation angles. Chapter 7 provides a useful outline, particularly in the first part, to show how robot movements are generated. The section on Active-X event processing needed more details – see S4EventLogger.vi description below. Chapter 8 was presented in outline only and this detailed documentation provides what is missing there. Andrew's most lasting contribution was to sort out how Active-X controls can be used to link LabVIEW with the ABB Robot S4 controller package RobComm.

I took over at the final stage of commissioning the telelabs software system that Andrew had started: Andrew was too busy with final exam preparation. I had to revise the structure of the 'run hardware' level and had a frustrating time trying to work out why some status change events were never received. Once this was resolved the rest was routine and I largely followed the telelabs templates for the hardware and remote clients.

There are several significant deficiencies that need to be remedied in the short term.

When the robot was briefly made available for public use over the weekend of 19th December, one user managed to crash the robot into the table. I am not sure how. The main issue was that we had no log files that recorded the robot movements so they could be played back for checking.

We urgently need a system to make users responsible: a registration system, so that we can track users and deny access to troublesome ones.

Hardware Conference

2008-11-15T21:09:00.001-08:00

Software and Complex Electronic Hardware Conference Information for Designated Engineering Representatives (DERs)
How may a Software/CEH DER meet recurrent training requirements?
To meet recurrent training requirements, all DERs must attend a DER Recurrent Seminar General Session plus a Technical Session for each of his or her engineering designation types.
There are ten engineering designation types distributed between six technical sessions:
1. Structures
2. Mechanical Equipment
3. Electrical Equipment and Radio
4. Powerplant, Engine, and Propeller
5. Flight Analyst and Flight Test Pilot
6. Acoustics
A DER may have a delegated function of Software and/or Complex Electronic Hardware approval in one or more of these designation types:
1. Electrical Equipment
2. Engines
3. Propeller
4. Mechanical Equipment
5. Powerplant
Software and CEH are not technical specialties, but rather, delegated functions in one or more of the five technical specialties.
Some DERs have only the Software and/or Complex Electronic Hardware delegated functions within one or more technical specialties. The Software/CEH Technical Session of the DER Recurrent Seminar Program was developed to specifically provide information to those DERs who have only the Software and/or Complex Electronic Hardware delegated functions, regardless of which technical specialties they hold. To meet recurrent training requirements, DERs who have authority for Software and/or Complex Electronic Hardware only may attend the Software/CEH Technical Session to fill the Technical Session requirement, but they are not required to attend this session. Otherwise, DERs with authority for Software and/or Complex Electronic Hardware only must attend a Technical Session for their technical specialty, even though Software or CEH topics may not be specifically discussed in that session. DERs with authority for Software and/or Complex Electronic Hardware only in more than one technical area, who do not attend the Software/CEH Technical Session, may attend the technical session deemed by their advisor to be the most appropriate to the work performed.
DERs who are authorized for a delegated functions in addition to Software and/or Complex Electronic Hardware (i.e., they are not a DER with authority for Software and/or Complex Electronic Hardware only) must attend a Technical Session for that technical specialty.
What is the Software and Complex Electronic Hardware Conference and how is it related to the DER Recurrent Seminar Program?
The Software and Complex Electronic Hardware Conference is sponsored by the Technical Programs Branch of the FAA (AIR-120) to address Software and Complex Electronic Hardware topics and issues. It is not part of the DER Recurrent Seminar Program. However, because it is budgeted and planned on a year-by-year basis, the conference cannot be guaranteed in any single year.
Does the Software and Complex Electronic Hardware Conference count for DER recurrent training?
To meet recurrent training requirements, DERs with authority for Software and/or Complex Electronic Hardware only may attend the Software and Complex Electronic Hardware Conference in lieu of the required DER Recurrent Seminar Program Technical Session (either the Software/CEH Technical Session or a Technical Session for their technical specialty). These DERs with authority for Software and/or Complex Electronic Hardware only must still attend a DER Recurrent Seminar General Session at one of the DER Recurrent Seminar Program locations. DERs who are authorized for a technical specialty in addition to Software and/or Complex Electronic Hardware must also attend a DER Recurrent Seminar Technical Session for that technical specialty.

Hardware Sizing Recommendations

2008-11-15T21:08:00.001-08:00

For NetScreen-Security Manager Feature Pack 3
Introduction
This document offers some guidelines on NetScreen-Security Manager hardware sizing. However, the detailed system requirements for each NSM component can vary greatly from installation to installation, depending on the size and topology of the network, the type of logging to be managed and other factors. It is advisable for customers to discuss their current and projected device management requirements with a Juniper Systems Engineer in order to ensure their needs will be met by the hardware they select.
Formulas and Guidelines
There are four basic elements involved in sizing: single vs. dual system, memory, storage space, and processor speed requirements. Specific requirements for each system will vary, but there are some general rules and formulas that can be applied.
Single or Dual System for GUI Server and Device Server
The GUI Server and Device Server are the two components of the management server. The GUI Server stores all configuration data and manages the UI connections, and the Device Server stores logs and maintains connectivity to the devices being managed.
For managing more than 1000 devices, it is recommended to use two Network Interface Cards (NIC) for both GUI Server and Device Server systems. One of the NIC cards is dedicated for the connection between GUI Server and Device Server. The other NIC card is used for GUI connections and device connections for GUI Server and Device Server respectively.
The GUI Server and Device Server may be combined if you have fewer than 200 devices, small device configuration sizes (e.g. large number of NS-5GTs with a few larger systems), and fewer than 1000 logs per second from all devices. Add at least 1GB RAM to the recommended GUI Server RAM to support this configuration.
Memory Requirements
GUI Server
Many factors are involved in determining the memory requirements for a given system, however the biggest factor is device configuration size.

First, make note of the number and type of devices that will be managed by NSM, and their configuration sizes. Configuration sizes can vary widely based on the number of rules in a policy and the number of VPN tunnels. To determine configuration size for a device look at the first line of the output of get config on the CLI. This is the size of the configuration for a device in bytes. Take the sum of the configuration sizes to be managed and refer to the table below to determine the estimated RAM required:

Total Config Size GUI Server RAM Required
Less than 2 MB 512 MB
Between 2 and 10 MB 3 GB
Between 10 and 50 MB 4 GB
More than 50 MB 8 GB

Device Server
The key factor in determining the memory requirements for the Device Server is the number of devices being managed. Use the table below to determine the requirements for a given deployment size:

Number of Devices Device Server RAM Required
Less than 200 1 GB
More than 200 2 GB
More than 500 4 GB

GUI Client
For managing more than 1000 devices, it is recommended to use PCs with 1 GB of RAM. In addition, it is recommended to make the following change in the NSM.lax file in the C:\Program Files\NetScreen-Security Manager directory on the client machines:

Change

lax.nl.java.option.java.heap.size.max=384m

to

lax.nl.java.option.java.heap.size.max=512m

Storage Space Requirements
GUI Server
Beyond the storage space required for the device configurations, there are additional items to be considered in sizing storage space. The GUI Server binaries and libraries require less than 100 MB.
Other key components that are disk space intensive are:
• Audit Log
• Error Log
• Device configuration database
• Nightly backup
The storage space requirements for each component are described in more detail below.

Audit Log
Audit log will have large impact on disk space depending upon audit log detail option configured. There are three options can be selected in guiSvr.cfg file located in /usr/netscreen/GuiSvr directory:

guiSvrManager.auditlog_flag 1 (Audit log is completely disabled if set=0)
guiSvrManager.auditlog_detail_flag 1 (Audit summary only is enabled if set=0)

Operation Audit Log Detail OFF Audit Log Detail ON
Update Device 10K 136 bytes 40 KB
Update Device 30K 136 bytes 60 KB
Update Device 300K 152 bytes 240 KB
Add Device 2 K 5 KB
Login in/out 180 bytes 180 bytes
Save Policy 25 rules 48 bytes .01 MB
Save Policy 100 rules 64 bytes 0.5 MB
Save Policy 250 rules 512 bytes 0.75 MB
Save Policy 1000 rules 1024 bytes 5 MB
Save Policy 5000 rules 2048 bytes 15 MB

For example, in a system with 100 devices with 10 KB configuration size per device and 1000 rules, 100 device updates and 5 policies saves will use (100 * 40 KB + 5 * 5 MB = 29 MB) 29 MB with the audit log detail option on, whereas it will take only (100 * 136 + 5 * 1 KB = 18 KB) 18 KB of disk space with audit log details turned off.

Error Log
The /var/netscreen/GuiSvr/errorLog directory keeps error log files (guidaemon.0). It stores up to 25 files before the oldest log files are overwritten. Each day’s file may be up to 5 MB in size. Based on these default settings, error logs can consume up to 125MB (or 250 MB if GUI Server and Device Server are on the same server).

Device Configuration Database
The size of the Device Configuration database can vary based on number of devices and types of configuration used. For every 1 MB of aggregate device configuration, NSM may need 200 MB disk space.

For example, 100 devices with 10 KB configuration may need (10 KB * 100) * 200 = 200 MB of disk space.

Nightly Backup
Nightly backup will maintain 7 copies of the GUI Server database if the default installation option is selected. The disk space requirement should be 7 * (device configuration database size calculated above).

Device Server
Storage capacity requirements are determined by the following equation:

(Retention period in days * Events per day * 200 bytes)/ 1,000,000,000 = storage size in GB.

Log events average around 200 bytes each. Following is a chart with some examples based on a retention period of 30 days:

Events Per Day Storage required in GB
1,000,000 6
10,000,000 60
25,000,000 150
50,000,000 300

If traffic logs are turned on, they generally comprise about 2/3 of all logs; so turning off traffic logs can result in a large savings in storage space.

In NSM, logs are stored in /var/netscreen directory of the Device Server by default. The /var directory should always be mounted on a separate partition or drive from / to avoid log files filling up your root partition and crashing your server. In situations calling for high volume logging, we recommend that /var be mounted on a locally attached high speed SCSI drive or similar performance storage solution. The path for log storage can be specified during initial installation.

In addition to regular logs, error logs may consume up to 125MB of storage space on the Device Server.

Processor Speed Requirements
GUI Server
A faster CPU in the GUI Server provides for a more responsive Log Viewer, and a faster feeling system overall. Our recommendation is to focus on a system that supports your storage and memory needs first, and get a mid-range to high-end processor for it. Dual processors have a negligible performance benefit for NSM, but may have additional performance benefits with future releases.
Device Server
In our testing, CPU speed had an impact on scalability on the Device Server in regard to sustained logging rates. A modern Intel or AMD CPU (i.e. 2.4GHz) or an UltraSparc III (1.2 GHz) is capable of handling sustained log rates in excess of 20,000 logs per second, while the SPARC processors in the Netra X1 that was used as a Global Pro Express appliance are able to handle fewer than 1900 logs per second.
A fast CPU on the Device Server is recommended for environments with high log volumes. For deployments using ScreenOS 4.0, maximum logging rates are approximately 1,900 events per second. For deployments using ScreenOS 5.0, maximum logging rates are approximately 20,000 events per second.

WORKSTATION HARDWARE

2008-11-15T21:06:00.002-08:00

APPENDIX E
WORKSTATION HARDWARE AND SOFTWARE STANDARDS
(1998-2001)

The following minimum standards to guide future computer hardware purchases were recommended by the Systemwide Internal Partnership in fall 1998 and incorporated into the Master Enabling Agreement with Inacom Corporation (1/21/1999). The principle behind the recommendations is that newly purchased computer hardware will be usable for three years from the date of purchase. These standards are therefore operative for the CSU Annual Campus Technology Survey for fiscal years 1999/2000 through 2000/01. Criteria for the survey covering FY 2001/02 will be based on revised recommendations made by the Commission on Technology Infrastructure in September 1999. For each survey period thereafter through the end of the reporting period, applicable standards will be those approved three years prior.

Minimum Hardware Standards for Windows Platforms

Recommended Minimum Desktop Hardware Standards (Effective FY 1998/99)

Processor Pentium® II processor 350 MHz with Intel 440 BX chipset
Cache: 512KB L2 cache integrated into the processor cartridge
Memory 64 MB of 100MHz SDRAM
Flash BIOS 2MB Flash memory
Graphics 8MB of 100MHz SGRAM, Advanced Multimedia Channel [AMC] video prot. Diamond, Matrox, or ATI 64/128 bit ABP board.
Audio Integrated full duplex audio [Sound Blaster Pro and Windows Sound System compatible]. External connectors for microphone, stereo input and stereo input and stereo-amplified output for speakers or headphones.
Hard Drive 6.4GB
EIDE EIDE Controller Integrated PCI
Floppy Disk Integrated floppy diskette drive support 3.5” 1.44MB diskette drive standard
CD-ROM: 20 x CD-ROM
Data Backup Internal
NIC 10/100Mb Fast Ethernet with ACPI and Wakup On LAN support, 10/100Base-TX, RJ45 twisted pair connector
I/O Connectors 2 USB, 2 serial, 1 high speed ECP/EPP parallel port, 1 PS/2 mourse, 1 PS/2 keyboard
Expansion Bus PCI, ISA, ACP and USB
Standards (ISO) 9002/ANSI/ASQC Q9002
Monitor 17inch FST with (0.27 dot pitch. Power consumption under 100W, 1024 x 768 resolution at 90 Hz
Sound Built-in stereo amplifier with 5 watt speakers. Bulit-in directional microphne. Low emissions, strict safety standard compliance
Operating Sys. Windows 98 or Windows NT 4.0

Recommended Minimum Laptop Hardware Standards

Processor 233 Mhz Pentium® II processor with Intel 440BX chipset
Memory 64 MB of 100MHz SDRAM
Hard Drive 4.0 GB hard drive
Display 12.1" TFT XGA display
Graphics 4MB of 100MHz SGRAM
Sound 16-bit SoundBlaster® Pro compatible voice and music functions
Operating Sys. Microsoft Windows 98, NT Workstation 4.0 (CD-ROM)
Modem 56Kbps, V.90 Upgradeable
CD-ROM: 20 x CD-ROM
External Ports Parallel, serial, VGA, PS/2, IRDA 1.1, USB, and docking port
Weight Maximum 8.0 pounds

Minimum Hardware Standards for Macintosh Platforms

Recommended Minimum Desktop Hardware Standards

Processor: 233 Mhz G3 (266 also available)
Memory: 64 MB RAM (32 MB extra memory optional)
Video RAM: 4 MB
Ethernet: 10/100BASE-T
Modem: 56 KB
Hard Drive: 4 GB (5.4 GB also available)
CD-ROM: 24 X
Monitor: 15" monitor, 800 x 600 resolution, built-in speakers, microphone
(17”, 1024 x 768 also available)
Keyboard: standard
Mouse: standard
Data Backup: Internal ZIP Drive (optional)

Recommended Minimum PowerBook Hardware Standards

Processor: 250 Mhz G3
Memory: 32 MB RAM
Ethernet: 10BASE-T
Modem: 33.6 KB
Hard Drive: 5 GB
Floppy Drive: 1.44 MB
CD-ROM: 24x CD-ROM (DVD encouraged - only in 400Mhz)
Display: 12.1”, 800 x 600 resolution

A Mathematical Model of Hardware Prefetching

2008-11-15T21:06:00.001-08:00

The time complexity of algorithms has traditionally been studied exclusively in terms of the instruction count. More recently, efforts to construct cache efficient algorithms have focused on adapting asymptotically optimal algorithms to the multiple tiers of the memory hierarchy. An additional hardware feature, though, makes several theoretically optimal cache efficient algorithms less effective in practice. The hardware prefetcher of the Intel Pentium 4 processor allows for bytes to be loaded from main memory into the L2 cache before being explicitly requested. To anticipate desired bytes, the prefetcher keeps track of previous cache misses. Its range is limited to 256 bytes ahead of current accesses and it can operate on up to eight concurrent data streams [1].

Given the magnitude of its allowed speedups, surprisingly little attention has been paid to studying the effects of the prefetcher for various algorithms. In the experiments of Pan et al., standard and cache efficient implementations of algorithms are studied with and without prefetching enabled. The prefetcher almost universally allows for significant improvement. For some of these algorithms, the prefetcher makes standard implementations faster than cache efficient ones, even when the cache efficient methods outperform standard ones without the prefetcher. This disparity implies that speedups delivered from the prefetcher are highly sensitive to memory access patterns. In order to understand these distinctions, a mathematical model of the prefetcher is developed.

Bookkeeping Management System.

2008-11-15T21:05:00.001-08:00

Hardware requirements for the LHCb Bookkeeping Management System.

Introduction
The conclusions made in this document are the result of the observations made on the server machines during the stress- test of AMGA server and while the Bookkeeping services are running for production.
The AMGA server was running on a dual processor machine (Xeon) of 2.4GHz each with 1 GB of memory. The bookkeeping production machine is a Pentium III of 850MHz with 768 MB of RAM.

Resource consumptions
AMGA has proven to be reasonably efficient in terms of resource consumption during the multi-client connections test. The memory consumption was around 10M per connection.
The only bottleneck to AMGA performance was the CPU which was fully used when 5 client where connected. ( see chart at http://www.physics.ox.ac.uk/users/cioffi/UKmetadata/Oxford/MultiClientsCon.xls). From the observation of the production system I could see that over few months very rarely three users were connected contemporaneously.

On the production machine are installed four python production servers, plus the Tomcat server. The same machine is also used as development machine with many other services running on it. All the services are supported very well by this old machine where a 33% average load is observed. None of these services is absorbing a reasonably amount of memory or CPU.

Hardware requirement
Based on the current use of the system by the Dirac developers and physicists a single dual-core machine as the one used for the AMGA testing will be enough to support the AMGA server and the other production services.
Based on the LHCb computing model where only one user will be the writer of the bookkeeping and all the others are readers, in case more than 5 contemporaneous connections are frequently exceeded, new instances of AMGA, with only read privilege, can be installed easily on separate machines.

Conclusion
It is my believe that a single dual-Xeon machine at 2.4 GHz with 1GB-1.5GB is sufficient to support all the bookkeeping Services till the real data taking from the detector.

Hardware Security Modules

2008-11-15T21:04:00.000-08:00

CREN Strategic and Practical FAQ – Hardware Security Modules
Hardware Security Modules – What to Look For
Web location: http://www.cren.net/crenca/onepagers/hsm.html
Draft 1.5, November 05, 2001
1. What is a Hardware Security Module (HSM)? How does it fit into my campus Certification Authority?
A Hardware Security Module is a hardware-based security device that generates, stores and protects cryptographic keys. It provides the foundation for a high-level secure campus certification authority. Certification modules are also available in software, but a hardware device provides a higher level of security.
2. How do I know if a Hardware Security Module is secure enough for my applications? Are there any universal criteria for rating these devices?
Yes, there are universal criteria for rating these devices. The criteria are documented in a Federal Information Processing Standard (FIPS) called FIPS 140-1 – Security for Cryptographic Modules.
This FIPS standard provides criteria for evaluating security modules – whether hardware, software, or some combination of hardware and software. The FIPS standard was developed collaboratively by the following agencies: the US National Institute of Standards and Technology (NIST), the US National Security Agency (NSA), and the Canadian Communications Security Establishment (CSE). Security devices are currently rated from FIPS 140-1 Level 1 to FIPS 140-1 Level 4. Higher standards may be developed in the future. The Level 4 standard is for the most rigorous security environments.
3. What is a FIPS 140-1 Level 3 Hardware Security Module?
A FIPS 140-1 Level 3 Hardware Security Module Device meets the FIPS 140-1 Level 3 or higher standard by supporting cryptographic key generation and storage within a hardware environment.
At this time, most institutional certificate authorities use a FIPS 140-Level 3 Hardware security module that cannot be physically accessed by unauthorized personnel.
4. Are there any advantages to using a FIPS 140-1 Level 3 Hardware Security Module rather than a software only security module?
A FIPS 140-1 Level 3 validated cryptographic module has a number of significant security and operational advantages over an equivalent software-based cryptographic implementation. The most useful advantage is the more secure environment. The principal value of these hardware modules is that keys can be generated and stored in these boxes, and provide strong protection against removal from the box.
By using hardware root-key protection from the beginning of deployment, an organization can achieve FIPS 140-1 Level 3 security at the outset. The inherent risks associated with software are mitigated because the root key will be and will always have been stored in protected hardware.
For additional information see: http://www.cren.net/crenca/onepagers/additionalhsm.html
5. Why should a campus have a Hardware Security Module?
The security and performance benefits offered by a hardware security device provide a critical component in the management and storage of private keys within a security infrastructure. HSMs also supply the infrastructure needed by the finance, government and healthcare sectors to conform to industry and regulatory standards.

6. What does the Hardware Security Module protect and secure?
The heart of trust in a public key infrastructure is the certificate authority (CA) that holds the root cryptographic signing key of the certificate authority. This signing key is used to sign the public keys of certificate holders, and even more importantly, signs its own public key. If this key is compromised, all certificates signed by the certificate authority are suspect, and the CA’s credibility is destroyed.
7. What are some of the additional protections of using a Hardware Security Module as part of a CA?
The security of a certificate authority depends on the right tools and the processes or policies using those tools. Here are some of the specific protections that can be achieved when combining a hardware security module with effective institutional practices and processes.
• Hardware may be less susceptible to system failures and corruptions, such as viruses.
• The content of the hardware module can be backed up to other hardware devices. If one set of hardware is destroyed, a backup set remains either on a duplicate hardware device or in a spare token or card set dependant upon your HSM model. Protecting the content is achieved with the combination of the hardware protections and good operational practices.
• Hardware can protect against internal and external intruders by using two-factor authentication: both the hardware device and a password can be required activate the root key.
• Hardware provides a higher level of security than non-secure media such as backup tapes, floppy diskettes, or smart cards, since the latter can be easily removed or copied.
• Hardware enables you to keep track of the number and locations of copies of root keys that exist.
• Hardware can enable an institution to support controlled access to the activation and use of root keys. Access codes can be distributed among several people who must cooperate to gain access to the root key.
8. What are some of the specific disadvantages of a software module or a combination of software and physical barriers to protect a CA?
Software or a combination of software and physical barriers to protect the root key has the following disadvantages.
• Software alone is vulnerable to viruses, inadvertent erasing, hackers, and complications from system failures.
• Physical barriers, such as vaults, and secured entrances are cost-prohibitive due to the expense of the initial investment and the on-going maintenance costs and do not adequately protect against insider attacks.
• Database backups of the certificate authority’s directory may contain a copy of the root key on each backup media, which are not secure and easily copied. This results in multiple copies of root keys existing at any one time with no assurance that additional copies have not been made and removed.
9. What are some of the best practices for an HSM architecture
Best practices are superior methods or strategies that are used by leading organizations to improve their security posture. See the following for a set of Best Practices on security assurance:

Experiment Hardware and Service Requirements

2008-11-15T21:03:00.000-08:00

Overview
A breakdown of the hardware requirements of each experiment is given at the end of this appendix, as a function of ‘LHC-year’; each year is taken April – April, roughly corresponding to the start of the LHC running period. Resources are taken to be the average available across the LHC-year; it is expected that resources will ramp up during each year to meet the requirements of ongoing data taking.
The CPU requirement at the Tier-1 is split into reconstruction and analysis needs; the reconstruction number also includes other strictly scheduled processing tasks such as skimming / stripping and event tagging, whereas the analysis CPU will be used on demand. For Tier-2, CPU is similarly split into simulation (scheduled work) and analysis (on demand). Units for CPU in the table are MSI2k (for reference, a modern 3GHz CPU is rated at around 1.4kSI2k per core). By convention, the storage requirements are for disk and tape ‘visible to the experiments’; they do not include operational overhead or the disk cache required for efficient tape operation. Units for disk and tape are PB.
UK Grid resources have been used during GridPP2 by at least fourteen distinct communities. In addition to the LHC experiments and BaBar, this includes running experiments at Tevatron, HERA and neutrino facilities, and use by phenomenology and lattice QCD communities. We expect this wide range of use to continue into the GridPP3 period. Whilst some of these activities will come to a natural close, we expect new users (e.g. the linear collider community) to become active. The computing plans of each of the smaller users have been identified during the requirements gathering process; however, we do not break down the requirements per experiment here. Instead, an envelope provision of 5% of total Tier-2 resource has been made in order to cover the requirements of smaller activities in each year. This is sufficient to cover the total need throughout the GridPP3 period, whilst allowing future flexibility in the allocation of resources between activities. We also allocate 5% of Tier-1 tape space for secure data backup by smaller activities, along with a provision of working disk at the Tier-1 to ensure efficient access to this data when required. An exception to this policy is UKQCD, which is broken out explicitly due to the large resource requirement in some areas (e.g. Tier-1 tape). It should be noted that the UKQCD requirement has not been carried through to the Tier-1 and Tier-2 planning at this stage.
We propose that, in order to prevent the justified requirements of smaller activities being put at risk by the inevitably large uncertainties in LHC needs, the corresponding 5% allocation should be considered separately from LHC during the ongoing resource allocation process within GridPP3. This continues the current GridPP2 User Board policy.
Contribution to global experiment needs
To illustrate the global situation concerning LHC computing provision, the overall Tier-1 and Tier-2 resources required by each LHC experiment in 2008 (as declared in their respective Computing TDRs) are shown in the table below, alongside the fraction of that resource which is currently funded via WLCG pledges from non-UK contributors, and the proposed UK contribution via GridPP3.
These estimates of requirements and pledged resources have associated uncertainties. Nevertheless, it is clear that in several areas, the requirements of the experiments cannot be met through the non-UK existing pledges. The proposed GridPP contribution for each experiment takes this into account, each experiment having fully considered the balance of UK resources which most effectively helps meet their global resource requirements.

Resource
ALICE ATLAS CMS LHCb
Tier-1 CPU
(MSI2k) Required 12.3 24 15.2 4.4
Non-UK Pledged 54% 89% 73% 85%
GridPP3 0.16 3.00 1.56 0.74
1% 13% 10% 17%
Tier-1 Disk
(PB) Required 7.4 14.4 7.0 2.4
Non-UK Pledged 36% 81% 75% 77%
GridPP3 0.11 1.78 0.84 0.41
2% 12% 12% 17%
Tier-1 Tape
(PB) Required 6.9 9.0 16.7 2.1
Non-UK Pledged 45% 90% 54% 74%
GridPP3 0.10 1.12 1.44 0.35
1% 13% 9% 17%
Tier-2 CPU
(MSI2k) Required 14.4 19.9 19.3 7.7
Non-UK Pledged 41% 83% 90% 38%
GridPP3 0.18 2.66 1.80 2.17
1% 13% 9% 28%
Tier-2 Disk
(PB) Required 3.5 8.7 4.9
Non-UK Pledged 40% 64% 92% (0.9 PB)
GridPP3 0.05 1.14 0.40 (0.007 PB)
2% 13% 8%

Table 1 Overall resource picture for LHC computing requirements in 2008.
Reference for global inputs: April 6th Regional Centre Capacities document, http://lcg.web.cern.ch/lcg/planning/phase2_resources/P2PRCcaps300606.pdf
Scientific justification for resources
ALICE
Although the UK makes up a small part of the ALICE collaboration, we play a vital role in the experiment being responsible for the design, construction and maintenance of the Central Trigger Processor (CTP) and Local Trigger Units (LTUs). This enables the UK ALICE group to have a proportionally higher profile within the experiment than our size would suggest. Being responsible for the trigger system also puts us in a strong position to fully capitalise on the unique physics potential of the ALICE experiment. It is, therefore, crucial that we contribute our fair share to the computing requirements of ALICE.

ALICE would like to make full use of the Tier-1 facility at RAL as well as the Tier-2s at RAL and Birmingham. The ALICE computing model and computing TDR set out our computing requirements. The ALICE collaboration expects funding agencies to provide computing resources on a pro rata basis depending on M&O authors. In practice, however, some funding agencies (many in Eastern Europe, Russia, China etc.) are unable to provide resources at this level and hence ALICE has a considerable shortfall in computing resources (currently about 50%). Western collaborators, such as the UK, are expected to provide their full quota and, if possible, more in order to help make up the shortfall. For example, Germany has pledged about twice the computing resources that their M&O authors would suggest.

The UK currently accounts for 1.2% of ALICE M&O authors. The minimum requirement for computing resources from the UK is, therefore, 1.2% of the total ALICE computing needs as shown in the table. The overall computing shortage within ALICE is a major concern and a larger UK allocation than the minimum would put the UK on par with other Western collaborators.

GIS Hardware

2008-11-15T21:02:00.000-08:00

GIS Hardware, Software, User Support and Data Configurations

Background

GIS technology has been in use for over 25 years. It has a proven track record in assisting land managers to correlate and analyze large amounts of spatial and tabular data, resulting in scientifically sound land management decisions. As with any tool, GIS is not appropriate in all situations. Offices where staff are supportive of GIS technology, in situations where the data will be used a number of times for analysis, on-going management activities, planning, or research are the most logical candidates for GIS implementation. Upper management should not mandate GIS technology if local support does not exist. Regional coordination can facilitate and assist local managers in evaluating GIS potentials.

Implementation of a major centralized GIS computing facility is not feasible for every region, but some centralized GIS coordination should be implemented either for the region as a whole or within individual programs. Centralized coordination can facilitate documentation and inventory of existing data bases, assist in coordination with other agencies on digital data transfer and interagency data sharing, and provide other specialized GIS services. The centralized coordination will increase enterprise benefits across the Service and will serve as a focal point for GIS activities within the Service.

Decentralized systems can easily handle incremental increases in users and applications as demand for GIS capabilities increases. Decentralized systems have the advantage of being more acceptable in a complex institutional environment where different organizational entities can better justify operating with a distributed processor. Given the geographically scattered locations of Service offices as well as the concept of ecoregion management, 'Nodes' and ‘Satellites’ should be developed within each ecoregion (or other manageable division such as a state) .

Organization

A node would be a major point of GIS activity and support for GIS needs within an ecoregion. It could support the needs of all Service organizational units within an ecoregion. Such a facility would provide the technical expertise and specialized equipment for any type of GIS needed by any of the Service programs. Example: Realty/Refuge Programs, within any given ecoregion, could work as a node or cluster in that ecoregion with support from the RO Refuge Division and in conjunction with co-located Ecological Services and Fisheries offices.

This parallels the deployment of other activities in an ecoregion such as efforts directed toward endangered species management or detailed work on a forest plan. It maintains some consistency between all programs within a field office in terms of reporting relationships, establishment of priorities, and budget setting.

A satellite would be an office with GIS capabilities but not at the same technical level as a node. Any smaller installation such as a remote refuge, smaller ecological services field office, or fisheries or migratory birds office could be a satellite. That office would depend on a node for major analytical capabilities, data entry, and other support. Satellite offices would be connected electronically to the node through the Internet. Biologists would then be able to use GIS software to make decisions using GIS data sets provided by the node.

Uncoordinated GIS activities, such as stand-alone computers, should also be incorporated into the GIS strategy. Some applications may not gain benefits from decentralized or centralized systems, and implementation of uncoordinated GIS could reduce initial costs and establish systems quickly for specialized applications.

Nodes, particularly their coordination activities, are necessary to insure some degree of consistency in the development, acquisition, and use of data within an ecoregion. Establishment of a node could be handled cooperatively between field offices, with one working analyst assigned the role of node coordinator. This person would be responsible for updating Ecoregion management on progress toward a coordinated GIS approach.

The role of the regional office in this scenario is to coordinate efforts across ecoregion lines and to provide internal and public access to metadata. Coordination efforts will often involve data acquisition or data standards. The ecoregions will focus on field level implementation (i.e. planning, staffing, equipment acquisition, data management, and analysis) with coordination and standardization within the ecoregion provided by a designated coordinator or a centralized ecoregion node.

Hardware Platforms

2008-11-15T21:01:00.002-08:00

FDMS Hardware Platforms, Operating Systems and Supporting System Software ---- Production Site (RTP) (May 5, 2008)
System Function Server Type Hardware Configuration Host Name Operating System (OS) Version Supporting System Software
FDMS Web Cache Server SunFire v440 Disk space 100 GB, 2 Sparc CPU’s , 4gb total memory, uerulepowc01 Solaris 9 Oracle 10g Web Cache Service
FDMS Web Cache Server SunFire v440 Disk space 100 GB, 2 Sparc CPU’s , 4gb total memory, uerulepowc02 Solaris 9 Oracle 10g Web Cache Service
FDMS Database Server Node 1 SunFire v890 Sun Fire V890 Server, 4 * 1.5GHz UltraSPARC IV+ processors with 32MB cache each, 16GB of DRAM (32 * 512MB DIMMS), 4 * 146GB uerulepodbn01 Solaris 9 + Sun Cluster 3.1 Oracle 10g R2 Database Management System
FDMS Database Server Node 2 SunFire v890 Sun Fire V890 Server, 4 * 1.5GHz UltraSPARC IV+ processors with 32MB cache each, 16GB of DRAM (32 * 512MB DIMMS), 4 * 146GB uerulepodbn02 Solaris 9 + Sun Cluster 3.1 Oracle 10g R2 Database Management System
FDMS Oracle LDAP Server SunFire v880 4@ 1200MHZ, 8GB, 6-73GB uerulepois01 Solaris 9 Oracle Infrastructure 10gAS
FDMS Oracle Application Server Node 1 SunFire v890 Sun Fire V890 Server, 4 * 1.5GHz UltraSPARC IV+ processors with 32MB cache each, 16GB of DRAM (32 * 512MB DIMMS), 4 * 146GB uerulepoasn01 Solaris 9 + Sun Cluster 3.1 Oracle 10g Application Server Service
10gAS
FDMS Oracle Application Server Node 2 SunFire v890 Sun Fire V890 Server, 4 * 1.5GHz UltraSPARC IV+ processors with 32MB cache each, 16GB of DRAM (32 * 512MB DIMMS), 4 * 146GB uerulepoasn02 Solaris 9 + Sun Cluster 3.1 Oracle 10g Application Server Service
10gAS
FDMS Documentum Content Server Node 1 SunFire v890 Sun Fire V890 Server, 4 * 1.5GHz UltraSPARC IV+ processors with 32MB cache each, 16GB of DRAM (32 * 512MB DIMMS), 4 * 146GB uerulepdcsn01 Solaris 9 + Sun Cluster 3.1 EMC Documentum Content Service
FDMS Documentum Content Server Node 2 SunFire v890 Sun Fire V890 Server, 4 * 1.5GHz UltraSPARC IV+ processors with 32MB cache each, 16GB of DRAM (32 * 512MB DIMMS), 4 * 146GB uerulepdcsn02 Solaris 9 + Sun Cluster 3.1 EMC Documentum Content Service
Auto Render Server DELL 2650 2 CPU, 4GB RAM nerulepdas01 Windows 2003 Auto Render Services
ColdFusion and Bulk File Transfer Protocol (FTP) Server Sun V240
2x1 GHz CPU, 4GB RAM, 2 x 72 GB HD uerulepftp01 Solaris 9 ColdFusion &
Bulk FTP Server
Web/FTP: ACIS/Ricochet DELL 2650 2 CPU, 4GB RAM nerulepkweb01 Windows 2003 Web/FTP: ACIS/Ricochet
Kofax Mgmt Server DELL PE 750 1 CPU, 4GB RAM nerulepkmgmt01 Windows 2003 Kofax Mgmt Server
OCR/PDF Conversion DELL 750 1 CPU, 2GB RAM nerulepkconv01 Windows 2003 OCR/PDF Conversion
OCR/PDF Conversion DELL 750 1 CPU, 2GB RAM nerulepkconv02 Windows 2003 OCR/PDF Conversion
OCR/PDF Conversion DELL 750 1 CPU, 2GB RAM nerulepkconv03 Windows 2003 OCR/PDF Conversion
OCR/PDF Conversion DELL 750 1 CPU, 2GB RAM nerulepkconv04 Windows 2003 OCR/PDF Conversion
Extensible Mark-up Language (XML)/DM Export/Staging DELL 2650 1 CPU, 4GB RAM nerulepkxml01 Windows 2003 XML/DM Export/Staging
WAN Boot Server Sun V240 2x1 GHz CPU, 4GB RAM, 2 x 72 GB HD Bootserv01 Solaris 10 Wan Boot Server
RSA Backup Server Sun V240 2x1 GHz CPU, 4GB RAM, 2 x 72 GB HD Rsaserv01 Solaris 10 RSA Backup
Endeca Search Engine 6000 Blade Server 4 Blades 2 Xeon Quad core CPU, 32 GB RAM, 360 GB HD Esearch01,02,03,04 Linux Red Hat Enterprise 5.1 Endeca Search Engine
Training Center
Content Server Sun V440 Disk space 100 GB, 2 Sparc CPU’s , 4gb total memory, Uerulecdcs01 Solaris 9 EMC2 Documentum content service
Oracle 10g AS
Training Center
Database Server Sun V490 Disk space 100 GB, 4 Sparc CPU’s , 8gb total memory, ueruletodb01 Solaris 9 Oracle 10g DB, and SSO
Redundant Server
Backup Sun V880 4@ 1200MHZ, 8GB, 6-73GB Uerulepoas01 Solaris 9 Repurposed for data migration
Index Server Sun
V1280 4 * 1.2 GHZ CPU 8GB RAM, 2 * 73 GB HD uerulepidx01 Solaris 9 Data migration
NetQos Monitoring Dell 1850 1 1.2 GHZ CPU 2GB Ram nerulepqos031 Windows 2003 NetQos Monitoring
NetQos Monitoring Dell 1850 1 1.2 GHZ CPU 2GB Ram nerulepqos02 Windows 2003 NetQos Monitoring
NetQos Monitoring Dell 1850 1 1.2 GHZ CPU 2GB Ram nerulepqos01 Windows 2003 NetQos Monitoring
Captiva Scanning Dell PE 2850 2 CPU, 4GB RAM nerulepcaptiv01 Windows 2003 Captiva Scanning
SMTP Server Dell 2650 21 CPU, 4GB RAM nerulepcfs01 Windows 2003 Email

Flight Hardware Criticality

2008-11-15T21:01:00.001-08:00

1. Functional Criticality - Categorization of the effect of loss of all redundancy
(like and/or unlike) for a given function (see Table 3.1). Functional criticality
for redundant items is based upon multiple failures which must occur to
result in loss of the system or component function. Any hardware item in
the failure scenario contributing to or resulting in the effect shall be considered
as “redundancy” (like and/or unlike, operational and/or standby).

2. Hardware Criticality* - Categorization of the singular effect of the identified
failure mode of a hardware item (see Table 3.2).
*Applicable to Space Shuttle Vehicle Engineering Office and EVA and Crew
Equipment Office only.

Table 3.1 FUNCTIONAL CRITICALITY DEFINITIONS FOR FLIGHT HARDWARE

Criticality Potential Effect or Failure
1 Single failure which could result in loss of life or
vehicle.

1R Redundant hardware item(s), all of which if failed,
could cause loss of life or vehicle.

2 Single failure which could result in loss of mission.

2R Redundant hardware item(s), all of which if failed,
could cause loss of mission.
3 All others.

Table 3.2 HARDWARE CRITICALITY DEFINITIONS FOR FLIGHT HARDWARE

Criticality Potential Effect or Failure
1 Loss of life or vehicle.

2 Loss of mission or next failure of any redundant item
could cause loss of life/vehicle.

3 All others.

NOTE: Hardware criticality is applicable to Orbiter and GFE elements only.

Ground Support Equipment Criticality

Criticality - The relative measure of the consequences of a failure mode. (See
Table 4.1 GSE Criticality Category Definitions.)

Table 4.1 GSE CRITICALITY CATEGORY DEFINITIONS

Criticality Potential Effect or Failure
1 Single failure which could result in loss of life or
vehicle.
1R Two redundant hardware items, which if both failed,
could result in loss of life or vehicle (or loss of a safety
or hazard monitoring system listed in Table 4.5).
1S Single failure in a safety or hazard monitoring system
that could cause the system to fail to detect, combat,
or operate when needed during the existence of a hazardous
condition and could result in loss of life or
vehicle.
2 Single failure which could result in loss (damage) of a
vehicle system.

3 All others.

Blackboard Minimum Hardware Requirements

2008-11-15T21:00:00.002-08:00

Blackboard developers recommended hardware specifications:
Minimum Hardware Requirements
PC Configuration:
400 Megahertz Intel Pentium III Processor (933 preferred)
64 Megabytes RAM (128 or more preferred)
6-Gigabyte Hard Drive
17" Monitor
56.6 Kbps Modem (or Cable Modem / DSL if available) Mac Configuration:
400 Megahertz iMac (933 preferred)
64 MB RAM (128 or more preferred)
6 Gigabytes Hard Drive
56.6 K Modem (or Cable Modem / DSL if available)
17" Monitor
Macintosh OS 9

Browser Test
Use the button below to check if your web browser is properly configured to use Blackboard

NOTE: With the new Blackboard 7 release there will be a link on the main page to ensure that the Internet Browser is properly configured to use Blackboard.

WIMBA

Supported Operating System, Browsers, Java versions and System Requirements for Live Classroom
Below, you'll find the supported Operating Systems, supported Internet Browsers, and recommended system specifications for using the Live Classroom.
Student Requirements
• 128 MB RAM (256 MB recommended)
• Internet access at 56k or above
• Soundcard w/ mic and speakers Instructor Requirements
• 256 MB RAM (higher recommended)
• Broadband Internet access
• Soundcard w/ mic and speakers
Wimba recommends using headsets (such as Plantronics DSP 500) instead of external speakers or microphones, particularly built-in microphones of laptops
Live Classroom Supported Operating Systems, Java & Browsers *
OS Browser Java (JRE)
Supported Unsupported
Win Vista1
Win XP
Win 2000 Internet Explorer 6.0 - 7.0 1.6 (6.0)
1.5 (5.0)
1.4
Firefox 1.5 - 2.0
Other AOL, Opera
OS Browser Java (JRE)
Supported Unsupported
Mac OS X2,3
10.4
10.3 Safari 1.2 - 2.0 1.5 (5.0)
1.4
Firefox 1.5 - 2.0 1.5.0.1+
Other AOL, Opera, IE
OS Browser Java (JRE)
Supported Unsupported
Linux4 Mozilla 1.0 – 1.7 1.5 (5.0)5
Firefox 1.5 - 2.0
Other Opera
* Browsers listed in the Supported section are recommended browsers for use with the Live Classroom. Browsers that are not listed have not been tested fully and therefore may or may not work with the Live Classroom.

LOCKWOOD DOOR HARDWARE

2008-11-15T21:00:00.001-08:00

0455 LOCKWOOD DOOR HARDWARE
Branded worksection
1 GENERAL
1.1 AIMS
Responsibilities
General: Provide door hardware in conformance with Selections. This information is to be used as a guideline for the preparation of a complete door by door hardware schedule.
Handing: Before the supply of hardware items, verify the correct handing on site.
Hardware specified generically: Provide hardware of sufficient strength and quality to perform its function, appropriate to the intended conditions of use, suitable for use with associated hardware, and fabricated with fixed parts firmly joined.
Installation: To the manufacturer’s instructions and to fulfil warranty requirements.
Operation: Ensure working parts are accurately fitted to smooth close bearings, without binding or sticking, free from rattle or excessive play, lubricated where appropriate to the manufacturer’s instructions.
Supply
Delivery: Deliver door hardware items, ready for installation, in individual complete sets for each door, as follows:
- Clearly labelled to show its intended location.
- In a separate dust and moisture proof package.
- Including the necessary templates, fixings and fixing instructions.
1.2 CROSS REFERENCES
General
General: Conform to the General requirements worksection.
Associated worksections
Associated worksections: Conform to the following: [complete/delete]
- ASSA ABLOY door by door hardware schedule.
Abbreviations
General: To AS 4145.1 Appendix D.
Definitions
Glossary of terms: To AS 4145.1 Section 2.
Lock functions: To AS 4145.1 Appendix E.
1.3 SUBMISSIONS
Samples
Generic items: Submit samples of nominated hardware items.
Particular samples required: [complete/delete]
Certification
General: Submit evidence of compliance with AS 4145.
Mortice locksets: Submit evidence of S3 compliance with the appropriate NATA accreditation.
Key control System
New works: Submit details of the proprietary key control system proposed by ASSA ABLOY Australia Pty. Ltd. or their certified agent for master keying the specified locks.
Delete this subclause if the proprietor installs a key control security system outside of the contract.
Alterations and additions: Submit details to extend the existing key control schedule for locks required to accept a group key.
Key schedule
Key details: Submit the record of the key coding system of ASSA ABLOY Australia Pty Ltd or the designated cylinder manufacturer showing proposed keying details, each lock type, cylinder type, number of, and type of key supplied, key number for re-ordering, and name of supplier.
Keys: For locks keyed to differ and locks keyed alike, verify quantities against key records, and hand over at practical completion.
Record documents
Door hardware schedule – Original: Submit a door by door hardware schedule, prepared by ASSA ABLOY Australia or their designated hardware supplier, if not already supplied as part of the Associated worksections.
Door hardware schedule – Amended: Submit an amended door by door hardware schedule, prepared by ASSA ABLOY Australia or their designated hardware supplier, showing changes to the contract door hardware schedule caused, as follows:
- By the approval of a hardware sample.
- By a contract variation to a door hardware requirement.
2 PRODUCTS
2.1 HINGES
Butt hinge sizes
Conform to tables as follows:
- Timber doors in timber or metal frames: Hinge table A.
- Aluminium framed doors in aluminium frames: Hinge table B.
- Cupboard doors: Not included in hinge tables.
General: Length (l) is the dimension along the knuckles, not including hinge tips, if any, and width (w) is the dimension across both hinge leaves when opened flat.
Butt hinge materials
Timber doors in timber or steel frames: [complete/delete]
- Product: Lockwood series.
Aluminium framed doors in aluminium frames:
- Product : Lockwood Interfold stainless steel or high tensile aluminium with fixed stainless steel pins in nylon bushes, and with nylon washers to each knuckle joint.
Doors fitted with closers: Provide low friction ball bearing hinges.
Fire doors: To AS 1905.1.
Power transfer hinges: Ensure they do not assume any load and are installed with compatible other hinges.
2.2 HINGE TABLES
Selection
Hinge table A applies to solid core doors and can be used to determine the quantity of hinges required for the nominated door leaf sizes and weights only. For door leaf sizes not specified or with applied finishes use the weight of the door to determine the quantity of hinges required. For door leafs over 80 kg, nominate pivot hinges.
The size of the hinge is determined by the door leaf thickness:
- 35 - 43 mm thick door: 100 x 75 mm # butt hinges with a minimum thickness of 2.5 mm.
- 44 - 55 mm thick door: 100 x 100 mm # butt hinges with a minimum thickness of 2.5 mm.
- > 55 mm thick door: Refer to the door by door hardware schedule.
Hinge pin: The symbol # refers to the pin type. Supply fixed pins to doors opening out or designated as a security doors.
Wide throw: If necessary, provide wide throw hinges to achieve the required door swings in the presence of obstacles such as nibs, deep reveals and architraves.