As you can probably guess from the title… I’ve been laid off from my mechanism controls position. My company had been doing layoffs for about 3 ½ years at this point so I lasted pretty long.

I’ve worked in the Aerospace industry for over 11 years now and there are some things I just don’t get.

“You can’t cut your way to growth”

During a down turn for a company they often times go into a serious cost cutting mode. Typically this means you pick up more of your health insurance, the cleaning crews stop coming, and the admins are no longer allow to provide napkins and plastic forks in little kitchenettes. Usually it also means layoffs, small raises and no promotions.

Obviously when the company is making less money it makes sense for that company to cut expenses. However, there’s an adage in business though – “You can’t cut your way to growth.” In other words you can’t just cut costs and expect to grow. Sure most companies are a little fat during good times so some targeted layoffs at the beginning of a downturn makes sense. But deep cuts in staffing don’t make sense from a long-term business standpoint.

Thoughts to consider when cutting staff

My premise is that a certain level of staff cutting is detrimental. And most people would probably respond with a “DUH!”

In my experience, in the Aerospace industry, most companies cut way too many people. Companies cut and cut and cut and cut and… Until they get profitable again. But the cutting rarely has anything to do with why the company (at least in the Aerospace industry) became profitable again. Typically the company has devoted a lot of resources to winning new sales and when it rains it pours. The company wins a big contract or a couple of them and now they don’t have the capacity to fill that contract without hiring. Now with each contract/sale won new people need to be hired.

New people require training and even when they walk into a job pretty much ready to go there are still processes and people to learn. Your older engineers, who are often in a position to define the direction and design of new products, are the only real exception. But the cost of hiring new people isn’t the only cost to be considered.

When companies cut too many people they lose capabilities. Those capabilities are lost both in the here and now and in the future. Not only are those capabilities lost but they have moved – most likely to a competitor. Along with the skills that those engineers have the company also loses all those half formed thoughts for new products or a better way to build or use an existing product.

Slow times are an opportunity – an opportunity usually squandered

In the Aerospace industry most of the products take years to develop. When times are good for the company is going gang-busters making what they promised to make. However, everyone is busy so who has the time to devote 10/20/30 hrs a week to a program that might fail? Ever work on one of those during busy times? I have and at best it seems you are ignored for your failure. At worst it harms your reputation within the company. Never mind that you put in lots of unpaid hours chasing a new product that is often someone else’s brain child – someone who doesn’t bother to stick around long enough to implement it.

Slow times at a company are an opportunity to improve processes, explore new technologies, and pursue more higher education. At my last employer I advocated using the slow time to allow senior engineers the opportunity to pursue their pet projects or more education while splitting their duties on current programs with junior engineers. That way the junior engineers can be brought further along and made more capable. The senior engineers can pursue projects that lead to future products. Everyone wins, the company has new products to sell, new capabilities to market, and the engineers’ career continues to move forward. The usual alternative is to give small or no raises and very few promotions. In this case, everyone loses it’s just a matter of degrees.

When modeling real-world systems for control it is often necessary to deal with a realistic approximation of the noise and disturbances the system is likely to experience.  For satellites with pointing systems this often means that a disturbance PSD is created or measured.  This disturbance is modeled as a random process whose energy is described by the PSD.  The PSD is applied to a State-Space model which represents the structural characteristics of the system – specifcally the characteristics of the transmission this disturbance energy to various portions of your system.

All of this starts with a PSD so we define a PSD class

classdef psdData

....

end

From here we define our properties, methods and events.  Since this will be a stand-alone class for holding and manipulating data, there are no events.  So what properties do we need?

• Bare Essentials
  • Name: Name the PSD data
  • Freq: Vector of Frequencies at which Magnitude data is captured
  • Mag: Vector of Magnitudes measured
  • RootPSD: Is this a a root PSD – in other words the units are something like rad/rt(Hz) instead of rad^2/Hz?
• Plotting Essentials
  • UnitBaseMag: Base unit for magnitude measurements
  • UnitBaseFreq: Base unit for frequencies at which magnitude measurements are captured
  • PlotFreqUnit: Frequency Units desired on PSD Plot
  • TimeUnit: The UnitBaseMag just holds a value like radians or degrees or m or ft.  If the measured magnitude is a rate – rad/sec or m/sec then this holds that the TimeUnit is 1/sec

The reason the units are broken up into base and time portion is because we will be including methods to integrate and differentiate the PSD.  In my industry rate PSDs are often the easiest to measure.  As a result we often get rate PSDs (in rad/sec) but need an angular (position) disturbance PSD so we end up integrating the measured rate PSD.  So it only makes sense to incorporate integration and differentiation into our class.  I’ll deal with the methods in a later posting

Now that we have a list of properties we need to decide access priviledges.  See a full list of Class Property Attributes here.

I hardly used MATLAB 2008a and never installed 2008b because of the shear amount of time it required to solve all of the stupid little issues with Mathworks new installation procedure.  I hate it and they should get rid of it.  However, in MATLAB 2008a Mathworks introduced a huge change to their classes.

In some of my work creating classes makes a lot of sense.  However, in previous versions building a class was an excrutiatingly slow and painful process requiring the developer to create a multitude of m-files for setting and getting properties, for displaying the data, and other basic infrastructure.  In 2008a MATLAB came out with a new way of programming classes which – at least for small, simple classes – greatly reduces development time.

In MATLAB 2008a, many of the infrastructure m-files you used to have to build for classes disappeared.  The entire class can be held in a single file if desired.  This one file can contain properties, events and methods.  For my purposes I usually end up with a few m-files containing helper functions for certain pieces of codes that are required in several places.

Over the course of the next several blog posts I’ll be going through an example of a class I built in about a day.  I’ve also found that making tweaks is very easy since there are far fewer files to deal with and many changes made to methods take effect immediate without the need to destroy and recreate the instance of class you are testing.

The example class will be a class for holding and plotting PSD Data.  Something very useful for Stochastic controls.

I’ve had a hard time identifying good industry rules of thumb for conservative controls design. So I’ve started a category on the wiki named “Rules of Thumb”.

These rules of thumb should provide inexperienced controls engineers with guidelines to a good design. For experienced engineers, I hope we will find these rules of thumbs to be informative about how other industries design their systems. We may even find that another industry’s common practices make sense for our own.

Please add whatever rules of thumb your industry uses.

Respect the Unstable

Back in August of 2003 I read an article in IEEE Control Systems Magazine titled “Respect the Unstable”, pp. 13-25, by Gunter Stein. The article made an immediate impression on me. The thrust of the article falls into what I call the “Controllers are Not Magic” category.

Most of the engineers I’ve worked with do not fully appreciate what controllers actually are. Nor do they fully understand what a controller can and cannot accomplish. So every so often I get requests for “Magic” in the form of “Don’t worry about Problem A, we can fix that with the controller.” Let me restate the obvious for anyone new to the controls field – Controllers are NOT Magic they manipulate physical systems and as such acquire the limitations of those systems.

The article by Dr. Stein provides an interpretation of the Bode Integrals as well as several examples of unstable systems.

The Bode Integrals

I’d put the equations here but I haven’t figured out how to do that in WordPress yet. So I’ve included a link the Bode Integrals on the wiki site here:
Bode Integrals in the Wiki

Here are my highlights from the article:

Basic Facts of Unstable Plants

Unstable systems are fundamentally, and quantifiably, more difficult to control than stable ones.

Controllers for unstable systems are operationally critical.

Closed-loop systems with unstable components are only locally stable.

and

The first integral applies to stable plants and the second to unstable plants. They are valid for every stablizing controller, assuming only that both plant and controller have finite bandwidths. In words, the integrals state that the log of the magnitude of sensitivity functionof a SISO feedback system, integrated over frequency, is constant. The constant is zero for stable plants, and it is positive for unstable ones. It becomes larger as the number of unstable poles increases and/or as the poles move farther into the right-half plane. (Technically, we must count all unstable poles here, including those in the compensator, if any.)

This is the equivalent of a conservation of energy for systems under control. The result being that to make a system less sensitive to disturbances in one frequency range the controlled system must become more sensitive in another frequency range (or all other frequency ranges).

In my current position we are often designing controllers to have good disturbance rejection at low frequencies while shooting for a minimum of peaking. The Bode Integrals make it obvious that low frequency disturbance rejection means more peaking in the higher frequencies. Sometimes the largest magnitude of the peaking can be reduced but that just means the peaking gets spread out in frequency. This observation of the Bode Integrals informs us of the limitations of controllers – we can’t have it all. So we now realize that our controller design is largely a matter of choosing the shape of our frequency response very carefully.

Dec. was a rough month.  I was working a lot of hours while juggling the various family obligations of the holiday season.  Work has slowed down a lot – too much really – so I should have some time to post this week.

Now I just have to get my brain back on line so I can think of a topic.  Feel free to suggest one in the comments area.

Sorry to say this but my “real” job is going to take up most of my time for the rest of December.  I’ve worked a lot of extra hours over the last couple of months.  I will probably continue to work extra hours for the rest of December.  (Right up to the end of my current program; most likely resulting in being laid off in Jan.)

As a result of the extra hours, I have to choose between time with my kids and time with my website.  Sorry again but I’m choosing the kids.  I’ll do my best to post as often as I can in the next couple of weeks.

Sensor Models

Given that sensors are vital to feedback systems I’ve included a bunch of sensor models.  You can see the New Sensor Models by clicking the link.

I’ll be adding more in the future as i get the time.

Source:  http://cr4.globalspec.com/thread/29317#newcomments

Hello Members,

Please go through this BBC story of the Chinese built/launched communications satallite for the Nigerian government. Here http://newsvote.bbc.co.uk/2/hi/africa/7726951.stm

The satellite was launched about two years ago and it is confirmed packed up.

Apart from the indicated power problem, what could be other causes of the satellite failure?

Cheers,

ethobil

Observations

The BBC article stated that the Nigerian satellite

1. … was limited because the type of frequency it used was disturbed by clouds in the atmosphere, and did not work properly in Nigeria’s rainy season or during the Harmattan, when clouds of dust blow down from the Sahara, he said.
2. … also operated on frequencies already allocated to other companies and interfered with other providers’ equipment.
3. … controllers shut the satellite down because it was having problems with its power supply, the government announced.

The observations in #1 and #2 are items that I learned to look out for before I graduated with my Bachelors.

Background for Observation #2:  Operating a satellite on another satellite’s frequency is both extraordinarily rude and stupid.  Interference from the satellite assigned that frequency will make both satellites useless for significant portions of their design life.  Obviously this is to be avoided and there are agencies to regulate these frequencies.

Background for Observation #1:  This is amatuer hour stuff.  Anyone with satellite TV or satellite radio knows that weather interferes with transmissions.  The thing is, the impact of weather can be minimized if not eliminated if you pick the correct frequency.

You may be asking why I addressed #2 first and then #1.  The answer is this, Observaton #2 shows that the Nigerians didn’t do even the most basic homework and contact the proper authorities.  Observation #1 reinforces this notion through an ignorance of basic satellite operations and limitations.

Observations #1 & #2 demonstrate that on the Nigerian customer (at least those in charge) didn’t know the first thing about what they were buying.  Questions about operations, lifetime, and weather are pretty basic and I learned to ask those questions before graduating with my Bachelors.

The final Observation

Observation #3 is that the satellite was shut down for power problems.  This could be something like a battery failure, power subsystem failure, solar array failure, or ADCS failure (which could point the arrays or the whole satellite the wrong way).

Given that the Nigerians didn’t do their homework – to know which frequency to use for their communications satellite, nor did they do enough homework to contact the correct regulatory agencies – before buying an expensive piece of hardware it only makes sense that they didn’t do their homework regarding system testing.

My guess is that the Chinese bid cheap re-using a satellite they designed for someone else.  This is common practice to reduce cost and risk.  But there are always custom changes when requirements change or new, updated hardware is added to the design.  If you don’t test the integrated system properly the chances of failure are high.  The Nigerian satellite was probably a recycled telecom satellite from another customer and some component of power system (like bateries) or the ADCS system (like attitude sensors or thrusters) was replaced.

An example of what I’m thinking…

An ADCS sensor, lets use a gyro for now, is replaced.  The new sensor comes from the same manufactuerer with the same power, size, and mounting requirements.  However, this new sensor provides its output in a different coordinate system such that 2 of the 3 axes (X & Y) are identical to the previous sensor but the 3rd axis (Z) is -1 of the original.  Without thorough design effort and proper integrated system testing, this -1 is easy to miss.  Then the whole satellite ends up pointed away from the sun and runs out of power.

The Nigerians missed the easy stuff, why would we assume they got the hard stuff, like proper testing, correct?

What finally worked

I have a quad core machine at my desk so I run multiple MATLAB windows.  These multiple windows allowed me to test some distributed computing processes.  As a result I set up a script for allowing the multiple windows to run.  I was using Stateflow in the model which requires a compile before each run.  As a result the model had to be run from a temporary directory.

This temporary directory was the first sign that the function, when distributed, is working.  The second sign was when the output file is saved.

Long story short, the batch command worked.  The batch command works but only with the PathDependencies and FileDependencies properties set.  The function is something like this

jj = batch(‘monte_sim_loop’, ‘matlabpool’, 0, ‘PathDependencies’, {…}, ‘FileDependencies’, {…});

The matlabpool set to 0 is important.  I tried to using a matlabpool of 3 for my initial runs.  It tied up 4 nodes but only run 1 instance of the sim.  Then I created a loop

for ii = 1:15

  jj = batch(…

end

The reason that a matlabpool of 3 tied up 4 nodes was that the matlabpool property is for how many additional nodes you want running.  It originally appeared to be an overhead function that was created.  A coworker discovered the matlabpool command already assumes 1 node and so anything higher than 0 ties up that many extra PCs for the 1 job task.  Since I just want my jobs distributed (not parallel) I set the property to 0.   When I ran the loop above, 15 computers were tied up and 15 nodes worth of results were produced.

If you know more, please share

I invite anyone and everyone who knows more about how to use the Parallel Computing Toolbox to share.  Use the comments to share.  Or if you like I welcome guest bloggers.

Thanks

Previous, related, posting

MATLAB’s Parallel Computing Toolbox First Impression