Why your UPS package never arrives

A while ago I got a peek into a UPS sorting delivery center facility while the machinery was in operation and gazed upon it from an engineering POV. Outsiders might envision UPS sorting and delivery as a highly automated process, but it is not.

The "automation" part consisted largely of quite conventional conveyor belts, chutes/slides and such. There was not nearly as much as I'd expected in the way of high tech sensors/scanners or robotic actuators recognizing and shoving packages down chutes to the specific delivery trucks; humans do most of that stuff.

Aside from incoming package barcode scans and application of an additional label to designate target delivery truck (humans will subsequently read this target truck label, not machines), 99% of the electro-mechanical sorting system could have been constructed with dawn of the 20th century industrial technology.

No distinction in handling is made between UPS letter size packages and say a 50lb box of sheet-rock screws headed to some construction site. Pricy guaranteed next day express type things do get somewhat different handling, but ordinary non-express items do not. Requiring a delivery signature, or having something insured for a bunch of money, doesn't impart any special status to a package during the transport/sorting/truck loading process.

Ordinary UPS package handling is even more equal than the animals in Orwell's Animal Farm -- there are no pigs who are more equal than others.

The conveyor belts and chutes do not discriminate

Packages and their contents are routinely ripped asunder vanishing into the maw of the process with absolute equality. If grandma's heirloom crystal, that's packed in a non-bullet proof manner, is landed on by the 50lb box of Hilti fasteners, it will be smashed into shards without hesitation like Godzilla crushes taxi cabs and buses oblivious to their presence.

The machinery makes no attempt whatsoever to segregate very light weight packages from very heavy, or odd shaped things from more ordinary boxes. If your small fragile box happens to wind up behind a heavy crushing brute, then you win, it doesn't get crushed. If its in front, then it gets battered, repeatedly, and unmercifully, sometimes into oblivion, as the boxes circulate endlessly around the belt system awaiting a human to pluck them off and send them down a chute to some particular truck for delivery.

"Fragile" warning tapes and "This end UP" type makings senders so optimistically apply simply don't factor into the system at all. They're totally ignored by the machinery and people who manually handle packages. Totally. Don't even bother; increase the quality of your packing jobs instead.

Remember the old commercial for American Tourister luggage with the gorilla baggage handler tossing things around like a rag doll? Pack as if that's what's going to happen, because it will, and your stuff might survive the UPS sorting process. If you pack flimsy, its strictly luck of the draw where your packages wind up on the conveyor belts and chutes if they'll survive.

As I walked around, the smell of wine was heavy in the air, clearly someone's inadequately packed case of wine had fallen victim to the machine recently. The floor was littered with bits of paper that looked like remains of some sort of pamphlets, stray bullets rolled around from some busted open boxes of ammo, along with considerable banding that had been torn off cases, and empty remains of boxes marked the passing of contents unidentifiable and scattered inside the soulless machine awaiting an end of shift cleanup crew to scoop them up and consign them to a trash bin.

So, if your package doesn't arrive, it probably wasn't "lost" in the sense of it got tucked behind something and forgotten, there's actually very few places in a UPS facility where one might tuck something away and have it get permanently forgotten. It was far more likely it was simply chewed up and physically digested by the machine to the point where it was no longer a deliverable package.

Based on what I observed, here are some recommendations for a successful UPS shipping experience.

• Pack sturdy. One strip of tape on a box flap seam IS NOT ENOUGH (Amazon, I'm looking at YOU bud). Tape each flap distinctly, then one around the whole mess. Think hard about using filament strapping tape applied around all 3 box axis, then cover that with ordinary packing tape.
• Don't use paper as filler on larger boxes. It has no resistance to crushing and box tape seams WILL FAIL under crushing load and contents WILL spill out and the package contents be lost.
• Select boxes sized to contents. Overly large boxes with small contents rattling around inside DO NOT fare well at all.
• Loose heavy metal/wood objects that are long act like battering rams and blow out the end flaps on long thin boxes, then the contents slide out and are consumed by the machine and the package gets destroyed.
• Do NOT affix UPS shipping labels so they span a box's flap seams. Use a box flap or sides.

Fashion chic using recycled plastic bottles

interesting how the fabric is made

Programming lessons - Finite State Machines(FSM's)

Wait a minute, that looks like an ordinary light switch, not some nerdish computer programming math'y gorp. Well, the lowly light switch is the perfect physical embodiment of a Finite State Machine, albeit a rather simple one.

If I were to start jabbering on about Digraphs or Multigraphs, your eyes would glaze over and you'd rightly wander off to go watch cat videos, so we gonna be talking light switches instead.

Light switches are something everyone has intuitive understanding of and there's not a whit of difference between what one can learn from them versus fancy jargon laden math'y graph shit. Switches now, jargon later.

 

 Ok, what is a Finite State Machine?

 

In the case of the simple light switch, its either on or off, and you can only try to push it up or down. It has two "states", on/off, and its possible "inputs" are limited to push up/down as well. IOW, its a simple "finite" "machine".

Suppose the switch is in its OFF "state", and you give it an "input" of "push down" - the light its connected to remains off, and there's NO CHANGE in the "state" of the switch; its remains in its OFF "state". Similarly, if the switch is in its ON "state" and you were to push it up, it remains in the ON "state".

In a computer program, this kind of "do nothing and return to previous state" behavior is like some prompt that wants a particular input, checks what you typed in, and reasserts itself if you typed invalid crap, and refuses to go away until you type in correct shit. Basically, the "machine's" behavior is: "invalid input fool, try again", which we've all experienced.

FSM's are often used like this to check the validity of input data, but that's not their only use.
A light switch that you only feed invalid inputs doesn't do much. Its only useful when you have it "transition" between ON/OFF "states" to turn your light on or off based on "input data" (i.e. shoving it up or down).

If we're in the OFF "state" and you shove the handle up, we "transition" to the ON "state" and voila, things are getting brighter. Shove it up again, things remain bright. Similarly, if we're in the ON "state" and you shove it down, darkness ensues. Shove it down again - still dark.

Once you started thinking about how the light switch "machine" reacts to different "inputs" when its in its various "states" you've got the basics of how a simple FSM works.

FSM's are mechanistic - predictable in their behavior, just like the light switch. They have no surprises. For a "finite" numbers of "states", with well defined "transition" rules between them for all possible "inputs", you will get the same predictable behavior every time.

That on/off light switch example was pretty simple. Now ponder what sort of light switch "machine" is needed to control something like a light that can be turned on/off by several switches in different locations.

The 3-way and 4-way switches used to implement that don't have ON/OFF "states" like the simple switch, they're either up/down and the light bulb can be on/off with any particular switch in the up or down position depending on the "state" of the other switches that control the light bulb. That "machine" isn't so simple anymore, but its behavior will still be just as predictable as the simple one. If any of the multiple switches are flipped to their opposite position, the light bulb will turn on if it was off, and off if it was on.

This is the power of FSM's -- absolute predictability even when things start to get more complex. Of course one of the problems is when a FSM has a design flaw, it will fail predictably in certain circumstances too. That known as a "bug".

A example of predictable failure is some traffic stoplights. Their behavior is very FSM'ish. Based on their various timing settings, how many cars are waiting over roadbed sensors, etc they have very predictable mechanistic behaviors. We've probably all encountered a situation where some turn lane never gets a green arrow though. You could sit there forever and the damned thing won't change UNTIL someone pulls up in back of you, then suddenly you get the arrow.

When this happens you'll notice there's usually two sections of roadbed sensors in the turn lane. If you pull far enough forward that you're only sitting on the front most sensor, then the machine doesn't think there's enough traffic stacked up to warrant issuing a green arrow. During the day when traffic volume is higher, this is never an issue as there's always several cars stacking up waiting for a green arrow.

The failure mode happens late at night when traffic looking to make a turn is sparse. If that next car doesn't come along for hours, you could be sitting there literally for hours waiting for one to show up and trigger that second sensor. This is a design "bug" in the traffic signal FSM. Tip: if this ever happens to you, just back up so you're sitting over the second sensor, then you'll probably get the green arrow right away.

Which brings up an interesting point -- people usually know enough to test systems under hard load, but some failure modes will happen BECAUSE OF inactivity or very light loads. Years ago IBM shipped a disk drive that worked fine when it was bein flogged hard, but failed when it was sitting idle for some particular period. There was a bug in the onboard drive electronics FSM.

By now you're noticing I haven't said much about "programming" since after all this was claimed to be a programming lesson. Programming a computer, in reality, is just the electronic embodiment of notions that could also be "programmed" with mechanical systems, hydraulic systems, manually executed by humans, or various combinations.

When you've created a design that is sound, how its specifically embodied becomes an implementation detail. When I'm designing some computer program I often visualize its internal machinations as whirling mechanical or hydraulic systems.

Once I've convinced myself that "machine" works and have debugged it as best a virtual construct can be debugged, I know I could write code in any one of hundreds of computer languages to actually implement that "machine".

A common mistake is to "go to code" before having a sound mental picture of how your machines are going to function.

IG: TSA's internal "Office of Inspection" kinda sucks

OIG 13-123 September 2013

DHS OIG took a look at TSA's internal inspection office and seemed fairly unimpressed with what they found. In fact they produced a 1-page executive summary that contains a section titled "Why This Matters" suggesting the IG believes this particular TSA OOI fustercluck is somewhat noteworthy compared to other more garden variety Federal agency fusterclucks.

The Office of Inspection (OOI) in the Transportation Security Administration (TSA) conducts inspections, audits, internal reviews, and covert testing to ensure the effectiveness and efficiency of TSA's operations and to identify vulnerabilities in TSA security systems. Additionally, OOI carries out internal investigations of the TSA workforce to ensure its integrity.
Approximately 60 percent of OOI's staff is composed of criminal investigators, who receive an extra 25 percent in pay, known as Law Enforcement Availability Pay (LEAP). As such, these positions are a more expensive resource than noncriminal investigator positions.

On to the findings:

OOI did not use its staff and resources efficiently

to conduct its work cost-effectively. OOI did not ensure that its criminal investigators performed criminal investigations the majority of the time, as required by Federal regulations. When performing duties unrelated to criminal investigations, criminal investigators were paid more than other OOI employees who could have performed the same work at a lower cost. In addition, OOI did not properly plan its work and resource needs, track project costs, or measure performance effectively. Quality controls were not sufficient to ensure that OOI's work complied with accepted standards; staff members were properly trained; and work was adequately reviewed. Finally, OOI could not ensure that other TSA components took action on its recommendations to improve operations.
As a result, TSA was not as effective as it could have been, and management may not be able to rely on the office's work. Also, OOI may not have fully accomplished its mission to identify and address transportation security vulnerabilities. With the appropriate classification and training of staff and better use of resources, OOI could improve the quality of its work. In addition, OOI could realize future cost savings of as much as $17.5 million over 5 years by reducing the amount it spends on LEAP if all of its 124 criminal investigators were reclassified to noncriminal investigator positions. However, the appropriate number of reclassifications and more precise cost savings cannot be determined without an objective and comprehensive review of position classifications
For the full The full 52 page IG report click here.

IG: DOT can't find 70% of its computers

Its not just healthcare.gov that's a major security risk. DOT/FAA has lots of security problems, issues with recoverability of data on system shutdowns, and apparently a major problem with finding stuff.

Report Number: FI-2014-006
Date Issued: -November 22, 2013

Highlights from FI-2014-006

DOT’s 13 OAs manage the Department’s 454 information systems. DOT relies on these systems to carry out its mission, including safe air traffic control operations, preventing unqualified drivers from obtaining commercial driver’s licenses, and identifying safety defects in vehicles. The Department must also protect billions of dollars for highway reconstruction, high-speed rail development, and law enforcement grants

• OCIO AND OAs HAVE NOT COMPLETED THE REQUIRED SECURITY PROCEDURES
• DOT LACKS THE ENTERPRISE-LEVEL CONTROLS NEEDED TO SAFEGUARD ITS IT SYSTEMS
• The Department Lacks Data To Track Required Security Training for DOT Contractors
• Most DOT Personnel With Significant Security Responsibilities Did Not Meet Specialized Security Training Requirements
• DOT’s Incident Reporting and Remediation Practices Reflect Minimal Improvement
• DOT Has Not Fully Complied With Configuration Standards

  To test DOT compliance, we selected a statistical sample of 994 of 79,759 computers from all OAs, but OAs could not locate 712 of the 994. Based on this, we estimate that OAs could not find 56,376, or 70.7 percent, of the Department’s 79,759 computers

. This is an increase of 14.3 percentage points from 2012’s 56.4 percent.

DOT Has Not Implemented All Required Controls for Configuration Management

We tested 55 systems and found multiple instances in which configuration controls had not been implemented or were only partially implemented, or documentation did not identify whether the control was in place (see Table 6)

DOT Continues To Lack a Comprehensive Departmentwide Risk Management Program

The Department’s Capital Planning and Investment Control Process Does Not Address IT Security

DOT’S SYSTEM-LEVEL CONTROLS ARE INSUFFICIENT TO KEEP SYSTEMS SECURE OR ENSURE RECOVERY

OAs That Use Cloud Computing Have Not Complied With Requirements

Despite Progress, the Department Continues To Have Problems Identifying Contractor-Operated Systems

DOT LACKS AN EFFECTIVE PROCESS FOR THE REMEDIATION OF SECURITY WEAKNESSES

There are just the IG report section highlights/titles, when you drill down into the specific sections, it gets even worse than it sounds here. I excerpted some of that type detail for two sections above. That's the kind of stuff you'll find in all the section details.

They don't know where 70% of their computers are?!?!
Seriously? No shit?

Putting a price tag on the NSA scandals

Nobody knows what the intel costs are yet, although they're undoubtedly substantial, but there's already commercial "collateral damage" - Boeing lost a $4.5B contract to Saab for new fighter jets for Brazil.

... a surprise coup for the Swedish company after news of U.S. spying on Brazilians helped derail Boeing's chances for the deal...

Jobs "created or saved": <0

Another NSA fallout victim is apparently IBM, who is being sued by shareholders and experienced a sharp decline in PRC business.

...IBM reported a 22 percent revenue loss from China in October, and a 4 percent drop in its Q3 profits...

China is apparently Cisco's largest market too given its rapidly expanding national IT infrastructure. If China goes wobbly on Cisco...