ece4006projectrequirementsdiscussion

ECE 4006 Project Requirements Discussion

From email exchange (gmail) between C. Mote and Endrias Woldegiorgis, April 23, 2005

Endrias,

Feel free to send me what you've got. I have been sick since mid-day

yesterday - I hope you are feeling better. I tried calling you this

morning to see where you all are at. I didn't think I was going to be

much more help at this point than reviewing the paper - I can't really

do anything for the presenation and y'all have to decide what is

working sufficiently at this point to include as a group. From what I

have gathered, it's going to be a bit limited - I think it is very

important to focus on the "detect breach" requirement and how massive

a task this was - it doesn't say "show if door open or closed" or

"find temperature in container" or "log data" - it says "detect breach

of cargo container". It's key to focus no this becuases it is so broad

- y'all need to show that the requirement was a bit unrealistic

(without actually saying so) and to point out every accomplishment you

had while pointing out the time and budget required were no where near

what was needed.

Send me what you've got or call me at my folks place - 770-804-8408.

Abracos,

Charlie

- Show quoted text -

On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:

> Hey Dud

>

> I would like you to review my portion of paper when you get a chance...

> I need help in writing

>

> Thanks a lot

>

> Endrias

>

>

Check this out, exactly as it appears on the project requirements as given to us by Prof. Bennet --

Sensing:

• Detection of breeching of the container walls, floor or ceiling (6 sides)

• Detection of opening, closing or removal of the container doors

• Container seal or lock status

• If there is a breech, you should be able to store and report the data

• There should be continuous monitoring with consideration to maintaining low false alarm rates

• The data should contain a history file with time stamped records of

all container events for that container trip

Dud by the way, you are always a help to me (ALWAYS)...

I'm not good in organization therefore I need help on the presentation.

How we should outline it. Me and B would like to take parts on it. Tell

me how we should start,  what we should have on the slides (like what

kind of pictures and so on) and the order we should present it.

Meaning, shall we do the experiment 1st or the presentation?

give me some inputs..

- Show quoted text -

On Apr 23, 2005, at 2:44 PM, Charlie Mote wrote:

> Endrias,

>

> Feel free to send me what you've got. I have been sick since mid-day

> yesterday - I hope you are feeling better. I tried calling you this

> morning to see where you all are at. I didn't think I was going to be

> much more help at this point than reviewing the paper - I can't really

> do anything for the presenation and y'all have to decide what is

> working sufficiently at this point to include as a group. From what I

> have gathered, it's going to be a bit limited - I think it is very

> important to focus on the "detect breach" requirement and how massive

> a task this was - it doesn't say "show if door open or closed" or

> "find temperature in container" or "log data" - it says "detect breach

> of cargo container". It's key to focus no this becuases it is so broad

> - y'all need to show that the requirement was a bit unrealistic

> (without actually saying so) and to point out every accomplishment you

> had while pointing out the time and budget required were no where near

> what was needed.

>

> Send me what you've got or call me - 770-804-8408.

>

> Abracos,

>

> Charlie

>

>

>

> On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:

>> Hey Dud

>>

>> I would like you to review my portion of paper when you get a

>> chance...

>> I need help in writing

>>

>> Thanks a lot

>>

>> Endrias

>>

>>

>

Hey Endrias,

Thanks for copying the requirements here.

The big question is, what currently works? I mean, what part of the

requirements have we actually met?

As I understand it, there's a circuit which turns on an LED if the

door is open and we can see this through the mote on the laptop -

perhaps it can be logged as well. We also have the peizo circuit,

although it isn't attached to anything and so doesn't send data

anywhere.

I think the best approach would be to start with the theoretical

solution following, point by point, the requirements. So, for example,

detection of breech of any of six (seven actually, the door is split

in half and therefore it's 7, not 6,) sides - how can the container be

breached practically speaking? I had found the data on the steel that

is used for these types of conatiners in the past, although I don't

know it of the top of my head. Let's say it's 1/8" inch corragatd mild

or Corten steel

(http://www.shippingcontainers.com/brchures.htm - used.pdf)

From here:

http://64.233.187.104/search?q=cache:ry_rjSpp7AsJ:www.ussconstruction.com/metal/metal/corten.shtml+corten+steel&hl=en

we know that COR-TEN steel is "a HOT ROOF" meaning it is relatively

highly heat conductive (from wikipedia "mild steel" is the most common

type of steel and is the lowest carbon content.) And here:

http://www.corrosion-doctors.org/Design/corrosion-performance.htm

points out the main difference between mild and corten, that being

that corten is more corrosion resistant in non-salt water

environments, so mild steel is probably pretty similar in terms of

heat conductivity.

It's this kind of detail the profs are going to want to see, and it's

the kind of detail that proves how much work you were expected to do

(that is, an unreasonable amount of work.) Statements like "lacking a

thorough materials engineering study of the exact details of the types

of steel used in the containers, many assumptions were neccesary for

the theoretical approach." need to be included to remind the prof.

that this was a massive undertaking - figuring out what types of

steel, in how many of the types of conatiners, with what kind of heat

conductivity and cutting/drilling resistance, etc. is a project for a

semester in-and-of itself.

But back to how to detect a breach. We know the containers aren't

hermetically sealed (i.e., air-tight), through annocdotal evidence

(news reports of human stowaways surviving in them) and discussions

like this:

http://www.ponl.com/topic/home_page/language_en/about_us/useful_information/cargo_care/condensation_issues

which talk about air and heat exchange between the containers, their

cargo and the environment, so we can't use (as you first suggested) a

simple means of detecting a change in pressure. Also, we can't expect

to pressurize all of the containers in the world, so that route is

just out.

As I wrote about in the first series of postings I made to the group a

few months back, that left just a few options.

Just stepping through each of these points, like I tried to do in my

postings, should point out how much work was neccessary for this

project, just to _meet_

the minimum requirements! Not to mention a detailed study of all the

various circuits and methods of wireless communication (as that one

prof of yours kept hammering with the "why xbow?" question) which

could have been used to meet them.

I think you should start the demo by stating that you could not meet

the requirements - always better to admit short-coming and then go on

to at least show what you have, than it is to proceed as if

everythings fine when it obviously isn't. "We attempted" is a phrase

you should probably use a few times.

I think you want to make it cleat that the group wasn't even really

considering true "real-world" requirements, like scalability,

retro-fitting costs, and possible compliance (meaning how many

containers would actually get systems like this due to the first two

considerations) and instead was focusing on just making a demo to test

some of the possible _concepts_ which further research would need to

address.

This is key - acknowledge we didn't get there, state that we never

anticipated actually getting there and that the exercise was to try to

test some of the _types_ of systems which _probably_ would be

neccessary to actually get there.

Then tell them, briefly, what was accomplished (in writing, this

should be a bullet-point list in order of most important to least -

including "procured volunteer labor [me] and donated materials

[cabinets, circuits, tools]" and listing them (what, I probably put in

around 100 hours of time ~ 30 min./day for 3.5 months (so ~ 55 hours)

plus several larger stints), cabinets, circuits, etc.)), including

creating and posting to the group, getting the motes from Hutto,

placing the orders, everything.

I might very well be able to write this part since I think I have a

pretty good grasp of the accomplishments.

The demo, however, should not have a whole lot of this, and shoud

stick to being a recounting of how much work would have been required

to meet the requirements and how much work it took just to get what we

have (the accomplishments) and then show them what we have. There

shouldn't be a "well, we almost got this part done, we had the parts

and ran out of time, etc." becuase it will seem like whinning - the

proper place to say that "we did at least get these parts" is in the

accomplishments part of the paper.

I'd try to stress this to everyone in the group - especially in

responding to the possible "why didn't you get there?" questions -

always go back to, "well, the requirements were... and we thought the

best theoretical solution was... and this is what we have." It won't

suprise me that these profs will pull this kind of "nose-in-the-air"

abuse, becuase the real answer as to why the "group" didn't get there

is that the profs didn't do there job of figuring out a "do-able"

project and then acting as the "boss" of a project and disciplining a

lack of performance - if they knew it was going to require each person

to put in X hours and obviously some members weren't, it was _their_

job to tell those people, point blank, "I'm going to fail you unless

you show evidence that you did your share", etc.

You, Bemmy and Nam should be proud of what you did accomplish and

shouldn't let anyone else whine about the realities (the impossibility

of the task you were given) and cheapen what you did get done. If

somebody does give a "well, we almost got done" response, I'd say you,

Bemmy and Nam should all speak up and say, "we didn't meet the

requirements and we understand we didn't plan sufficiently to reach

them" (which is not the truth - shit, more planning would have just

wasted more time and you would have had even less to show in the end!)

The demo should be a time for standing behind what you did get done

regardless of whatever criticism or continued slacking the others

involved (profs, group members, other students) try to inject.

So let me know what you think - I will probably just be at home

working all day Sunday - I know you will essentially be in church all

day and working on this at night - don't hesistate to call me at home

- I tried calling you tonight.

Let me know what I can do to help.

Abracos,

Charlie

P.S. - "Dud" is another word for "loser" - "Dude" is the common

hippie/surfer/college student slang for bro/"man"/friend/compatriot,

etc. I knew what you meant, but take note becuase "dud" and "dude" are

pretty much oppossites.

On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:

> You are sick?

> Check this out, exactly as it appears on the project requirements as given to us by Prof.Bennet > --

> Sensing:

> • Detection of breeching of the container walls, floor or ceiling (6

> sides)

> • Detection of opening, closing or removal of the container doors

> • Container seal or lock status

> • If there is a breech, you should be able to store and report the data

> • There should be continuous monitoring with consideration to

> maintaining low false alarm rates

> • The data should contain a history file with time stamped records of

> all container events for that container trip

>

> Dud by the way, you are always a help to me (ALWAYS)...

> I'm not good in organization therefore I need help on the presentation.

> How we should outline it. Me and B would like to take parts on it. Tell

> me how we should start,  what we should have on the slides (like what

> kind of pictures and so on) and the order we should present it.

> Meaning, shall we do the experiment 1st or the presentation?

>

> give me some inputs..

>

> >

> >

- Show quoted text -

> > On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:

> >> Hey Dud

> >>

> >> I would like you to review my portion of paper when you get a

> >> chance...

> >> I need help in writing

> >>

> >> Thanks a lot

> >>

> >> Endrias

> >>

> >>

> >

>

>

On Apr 23, 2005, at 11:31 PM, Charlie Mote wrote:

> Hey Endrias,

>

> Thanks for copying the requirements here.

>

> The big question is, what currently works? I mean, what part of the

> requirements have we actually met?

We still dont know how to use the vibration sensors. The company

clearly states that we could use it to measure not just vibration but

also earthquake. We think this can only be attained using MoteView or

factor software. Yet, as you recall, it was much harder to use MoteView

than TinyOS.

>

> As I understand it, there's a circuit which turns on an LED if the

> door is open and we can see this through the mote on the laptop -

> perhaps it can be logged as well. We also have the peizo circuit,

> although it isn't attached to anything and so doesn't send data

> anywhere.

We have the door sensors work like you suggested (which I thought was

the smartest idea). We used magnet sensors for the door, attached an

LED on top of the light sensor of one of the Mote-Sensor setup and

placed the device all the way on the back of the container so that the

light from outside would not interrupt the reading from the LED.

As for Peizo electric circuit designed by you, this was a very strange

result. Last night what I did was this, I took out the one of the light

sensors (photo diode) from the sensor board and attached directly to

the Peizo electric film. If i'm not mistaken, as we both thought, the

film itself should produce electric when bent or strained or stressed.

That was the reading we observed on the Scope that night. When we

obtain the reading from that particular node (from the node of the

light sensor), there is no change. So option number two was to use the

whole setup (circuit) and try to see if we can get any reading. The

reason I'm using the node of the light sensor is because I could make

the AtoD converter we ordered from Xbow. In fact, I even attached that

to the light sensor I took out from one of the sensor board and still

there was no reading. Anyway, so using the setup we had for the Peizo,

I still did not get any reading. Listen to this Charli, when I placed a

1.5V on the node of the light sensor, it reads the input BUT, was too

small. Therefore I'm thinking, that little light sensor produces so

much current in-order to get a reading. Even 9V battery did not produce

as much reading as the light sensor.

>

> I think the best approach would be to start with the theoretical

> solution following, point by point, the requirements. So, for example,

> detection of breech of any of six (seven actually, the door is split

> in half and therefore it's 7, not 6,) sides - how can the container be

> breached practically speaking? I had found the data on the steel that

> is used for these types of conatiners in the past, although I don't

> know it of the top of my head. Let's say it's 1/8" inch corragatd mild

> or Corten steel

> (http://www.shippingcontainers.com/brchures.htm - used.pdf)

Excellent idea. I will start with this on my first slide. Question,

1/8'' inch corragatd mild or Corten steel?

So the number 1/8'' is what?

>

> From here:

>

> http://64.233.187.104/search?q=cache:ry_rjSpp7AsJ:

> www.ussconstruction.com/metal/metal/corten.shtml+corten+steel&hl=en

>

> we know that COR-TEN steel is "a HOT ROOF" meaning it is relatively

> highly heat conductive (from wikipedia "mild steel" is the most common

> type of steel and is the lowest carbon content.)

But I thought this even suggested that suing Corten-Steel is not a good

idea although the containers are made using this kind of metal. I guess

we can use address/stress more the highly heat conductive behavior of

the container.

> And here:

> http://www.corrosion-doctors.org/Design/corrosion-performance.htm

>

> points out the main difference between mild and corten, that being

> that corten is more corrosion resistant in non-salt water

> environments, so mild steel is probably pretty similar in terms of

> heat conductivity.

Ok makes perfect sense. Yet why did the second link suggested not to

use it for roofing application? I know I know, you just want me to

focus on the heat conductivity property of the metal.

- Show quoted text -

>

> It's this kind of detail the profs are going to want to see, and it's

> the kind of detail that proves how much work you were expected to do

> (that is, an unreasonable amount of work.) Statements like "lacking a

> thorough materials engineering study of the exact details of the types

> of steel used in the containers, many assumptions were neccesary for

> the theoretical approach." need to be included to remind the prof.

> that this was a massive undertaking - figuring out what types of

> steel, in how many of the types of conatiners, with what kind of heat

> conductivity and cutting/drilling resistance, etc. is a project for a

> semester in-and-of itself.

>

> But back to how to detect a breach. We know the containers aren't

> hermetically sealed (i.e., air-tight), through annocdotal evidence

> (news reports of human stowaways surviving in them) and discussions

> like this:

>

> http://www.ponl.com/topic/home_page/language_en/about_us/

> useful_information/cargo_care/condensation_issues

>

> which talk about air and heat exchange between the containers, their

> cargo and the environment, so we can't use (as you first suggested) a

> simple means of detecting a change in pressure. Also, we can't expect

> to pressurize all of the containers in the world, so that route is

> just out.

>

> As I wrote about in the first series of postings I made to the group a

> few months back, that left just a few options.

>

> Just stepping through each of these points, like I tried to do in my

> postings, should point out how much work was neccessary for this

> project, just to _meet_

> the minimum requirements! Not to mention a detailed study of all the

> various circuits and methods of wireless communication (as that one

> prof of yours kept hammering with the "why xbow?" question) which

> could have been used to meet them.

>

> I think you should start the demo by stating that you could not meet

> the requirements - always better to admit short-coming and then go on

> to at least show what you have, than it is to proceed as if

> everythings fine when it obviously isn't. "We attempted" is a phrase

> you should probably use a few times.

>

> I think you want to make it cleat that the group wasn't even really

> considering true "real-world" requirements, like scalability,

> retro-fitting costs, and possible compliance (meaning how many

> containers would actually get systems like this due to the first two

> considerations) and instead was focusing on just making a demo to test

> some of the possible _concepts_ which further research would need to

> address.

>

> This is key - acknowledge we didn't get there, state that we never

> anticipated actually getting there and that the exercise was to try to

> test some of the _types_ of systems which _probably_ would be

> neccessary to actually get there.

>

> Then tell them, briefly, what was accomplished (in writing, this

> should be a bullet-point list in order of most important to least -

> including "procured volunteer labor [me] and donated materials

> [cabinets, circuits, tools]" and listing them (what, I probably put in

> around 100 hours of time ~ 30 min./day for 3.5 months (so ~ 55 hours)

> plus several larger stints), cabinets, circuits, etc.)), including

> creating and posting to the group, getting the motes from Hutto,

> placing the orders, everything.

>

> I might very well be able to write this part since I think I have a

> pretty good grasp of the accomplishments.

>

> The demo, however, should not have a whole lot of this, and shoud

> stick to being a recounting of how much work would have been required

> to meet the requirements and how much work it took just to get what we

> have (the accomplishments) and then show them what we have. There

> shouldn't be a "well, we almost got this part done, we had the parts

> and ran out of time, etc." becuase it will seem like whinning - the

> proper place to say that "we did at least get these parts" is in the

> accomplishments part of the paper.

>

> I'd try to stress this to everyone in the group - especially in

> responding to the possible "why didn't you get there?" questions -

> always go back to, "well, the requirements were... and we thought the

> best theoretical solution was... and this is what we have." It won't

> suprise me that these profs will pull this kind of "nose-in-the-air"

> abuse, becuase the real answer as to why the "group" didn't get there

> is that the profs didn't do there job of figuring out a "do-able"

> project and then acting as the "boss" of a project and disciplining a

> lack of performance - if they knew it was going to require each person

> to put in X hours and obviously some members weren't, it was _their_

> job to tell those people, point blank, "I'm going to fail you unless

> you show evidence that you did your share", etc.

>

> You, Bemmy and Nam should be proud of what you did accomplish and

> shouldn't let anyone else whine about the realities (the impossibility

> of the task you were given) and cheapen what you did get done. If

> somebody does give a "well, we almost got done" response, I'd say you,

> Bemmy and Nam should all speak up and say, "we didn't meet the

> requirements and we understand we didn't plan sufficiently to reach

> them" (which is not the truth - shit, more planning would have just

> wasted more time and you would have had even less to show in the end!)

> The demo should be a time for standing behind what you did get done

> regardless of whatever criticism or continued slacking the others

> involved (profs, group members, other students) try to inject.

>

> So let me know what you think - I will probably just be at home

> working all day Sunday - I know you will essentially be in church all

> day and working on this at night - don't hesistate to call me at home

> - I tried calling you tonight.

>

> Let me know what I can do to help.

>

> Abracos,

>

> Charlie

>

> P.S. - "Dud" is another word for "loser" - "Dude" is the common

> hippie/surfer/college student slang for bro/"man"/friend/compatriot,

> etc. I knew what you meant, but take note becuase "dud" and "dude" are

> pretty much oppossites.

I will take note of this: sorry if I offended you but I know you know

that my english is still in Africa. When ever I misspelled a word, I

say we dont have that word in Africa :)  like I think i misspelled

elevator on the of the store maps for inventory. The truth is, sure I

would misspell it because we did not have an 'elivator' in Africa.  : )

but on a serious not, thank you for addressing that to me. Now I

know...

I really hope you are feeling well. We are going to meet this morning

to do some testing. (i'm not going to church for this reason) and I

guess during the evening, me and B will be working on the portion of

our paper. This might leave you no time to review it, but I also hope

that we finish it with enough rest.

Charlie, I cant thank you enough for the help you have given us.

Oi Endrias -

I was assuming you would be at church - if you are at the lab and

someone there has a cell phone I can call to have you let me in then I

will be happy to stop by and see what I can do to help.

In the meantime, I am going to respond point-by-point:

> We still dont know how to use the vibration sensors. The company

> clearly states that we could use it to measure not just vibration but

> also earthquake. We think this can only be attained using MoteView or

> factor software. Yet, as you recall, it was much harder to use MoteView

> than TinyOS.

I don't think there is a vibration sensor on the sensor boards Hutto

gave us - I think Bemmy got confused on that a while back - I was

thinking about the peizo circuit.

> We have the door sensors work like you suggested (which I thought was

> the smartest idea). We used magnet sensors for the door, attached an

> LED on top of the light sensor of one of the Mote-Sensor setup and

> placed the device all the way on the back of the container so that the

> light from outside would not interrupt the reading from the LED.

That's great! This should be the center-piece of the demo and the

paper: accomplishment, requirement to detect door status. If you can

get this to be timestamped/logged on the labtop outside the TinyOS DB

that would be even better.

>

> As for Peizo electric circuit designed by you, this was a very strange

> result. Last night what I did was this, I took out the one of the light

> sensors (photo diode) from the sensor board and attached directly to

> the Peizo electric film. If i'm not mistaken, as we both thought, the

> film itself should produce electric when bent or strained or stressed.

> That was the reading we observed on the Scope that night. When we

> obtain the reading from that particular node (from the node of the

> light sensor), there is no change. So option number two was to use the

> whole setup (circuit) and try to see if we can get any reading. The

> reason I'm using the node of the light sensor is because I could make

> the AtoD converter we ordered from Xbow. In fact, I even attached that

> to the light sensor I took out from one of the sensor board and still

> there was no reading. Anyway, so using the setup we had for the Peizo,

> I still did not get any reading. Listen to this Charli, when I placed a

> 1.5V on the node of the light sensor, it reads the input BUT, was too

> small. Therefore I'm thinking, that little light sensor produces so

> much current in-order to get a reading. Even 9V battery did not produce

> as much reading as the light sensor.

>

Hmmm. So it's a 3V max on the inputs but needs a lot of current.

That's possible and I don't know any way around this. Document exactly

what you did since this is key to the rest of the requirements (and

why we didn't quite get there.) I'm suprised that you could get a 9V

to read at all since Xbow states all over not to put more than 3V on

the ADC or it will blow.

How could we possibly up the amperage coming out of the circuit

without changing the data?

Also, be sure to document how the peizo works on the O-scope - we need

to show that the line of thought, i.e., heat up, voltage down,

vibration up, frequency up, is valid and that it's a problem at the

interface (which is always very tricky) - that we got stuck on

converting the analog to digital and using it with this sensor

platform.

> Excellent idea. I will start with this on my first slide. Question,

> 1/8'' inch corragatd mild or Corten steel?

> So the number 1/8'' is what?

I just picked one-eigth of an inch (1/8") as a guess to the

approximate width of the steel the body (walls) of the conatiner are

made of - I couldn't find any citation anywhere for the actual

thickness. The point being that we know that the containers are

industrial steel and that they, therefore, are susceptible to all the

types of "breeching" (cutting, drilling, flame cutting/melting) that

industrial steel in general is.

> Ok makes perfect sense. Yet why did the second link suggested not to

> use it for roofing application? I know I know, you just want me to

> focus on the heat conductivity property of the metal.

I worked and lived in Central America and Brazil where people who can

afford nothing else use "galvinized" (rust-resistant) sheet metals for

roofing - those things get so hot you can fry an egg on them - so hot

in fact, that they radiate heat _down_ (heat likes to rise right?)

into the building, making the whole house heat up. This isn't bad if

it is a bit chilly outside, but it's not so great if you are trying to

keep the house cool. Also, since these sheets have no mass, as soon as

the sun is off them, they cook off, so none of the heat is useful at

night.

Heat conductivity - that's what led us to think that we would have a

shot at detecting a change in the heat flow if the attack was trying

to melt/cut a breech in the container.

> I will take note of this: sorry if I offended you but I know you know

> that my english is still in Africa. When ever I misspelled a word, I

> say we dont have that word in Africa :)  like I think i misspelled

> elevator on the of the store maps for inventory. The truth is, sure I

> would misspell it because we did not have an 'elivator' in Africa.  : )

> but on a serious not, thank you for addressing that to me. Now I

> know...

Not a problem - I'll probably be saying "Aa-marique" instead of

"a-Hamarique" for a good while...

>

> I really hope you are feeling well. We are going to meet this morning

> to do some testing. (i'm not going to church for this reason) and I

> guess during the evening, me and B will be working on the portion of

> our paper. This might leave you no time to review it, but I also hope

> that we finish it with enough rest.

>

> Charlie, I cant thank you enough for the help you have given us.

>

>

If you can, try to do a run through of the demo - just as you think

you will tomorrow - remember what I was talking about preparing for a

presentation - say it out loud just like you think you will - having

the thoughts already formed and the words already spoken will really

help.

Let me know what you all are up to this morning.

Abracos,

Charlie

This is what I have... just look into it when you get a chance...

Remember some of the postings you had, do you mind if I use them?

Design Alternatives & Tradeoffs: This section must contain a clear

explanation of other approaches that are possible and why they were not

used in the end product.  What were the technical tradeoffs and how and

why were the final alternatives selected.  In addition, include the

constraints that affected your project decisions. Include factors such

as economic, environmental, sustainability, manufacturability, ethical,

health and safety, social, and political where possible. This section

should include information about the method that your team used to

attack the design problem. Explain your constraints as well as your

solution.

Approaches that are possible

Breaching Detection

-       Pressure sensor

-       Gird/mesh of wire

-       Motion sensors

-       Piezoelectric Films

Detection of the breeching of the container wall, floor or ceiling,

detection of opening, closing or removal of the container doors, and

container seal or lock status are the design objectives of this

project. Different ideas were introduced for implementation, but were

not used in the end product for many reasons.

Breaching detection is one challenging aspect of the project. It

involves continuous monitoring of at least five sides of the container,

with minimum false alarm indications. The ideal detection methods

listed below present a functional and reliable monitoring technique;

yet could not be used in the end product for different reasons.

1)      Breaching detection

Grid/mesh of wire

The idea of using mesh wiring was first introduced to detect breaching

of the sides of the container. The walls of the container will be

dressed with mesh of wires through which a current is supplied with a

continuous power supply. The idea is that, during intrusion through the

walls of the container, the current flow through the wires will be

interrupted indicating breaching to the inspector. The mesh will not be

visible form the outside or inside. In order to protect the mesh from

accidental damage caused during loading and shipment process, each wall

of the container will be a double layer. In between, the mesh is paced

and supplied with a continuous power. This alternative is not used in

the end product of our design because of multiple reasons.

a)      The shipping industry isn't ready for mass production and deployment

of tamper-evident containers, and adoption is likely to come slowly.

Replacing the existing anywhere between 16 million and 19 million

containers used today could take another decade.

b)      The power supply would have to drive the current though the long

wires embedded in the walls. The power consumption will be highly

expensive.

c)      The budget given for this project is well below the manufacturing

cost of a container.

2)      Pressure Sensors

Containers aren't air-tight sealed. This is evident through anecdotal

reports like news reports of human stowaways surviving in them. Other

studies have proven to show formation of container sweat, which occurs

when the skin of the container is cooled to a temperature blow of the

dew point of the air enclose within the container. [ REFRENCE  1 ] This

results in water droplets forming on the interior roof and side panels,

then dripping down on the cargo causing mould and water damage. Cargoes

that spontaneously heat from within can increase the problem. This heat

exchange between the containers, their cargo and the environment,

proves to eliminate a simple means of detecting a change in pressure

within the container because the container is not air-tight sealed.

Also this design alternative will expect to pressurize all of the

containers in the world, which is beyond the scope of the project.

3) Motion Sensors

Removing a cargo or placing an object within the container can be

monitored using motion sensors. The motion sensors can be placed at 8

corners of the container, detecting motion from all possible angles.

Although this approach is possible and could provide sufficient

security, it was not implemented in the final product for these

reasons:

1)      When the container is filled with boxes or cargo, the object in

front of it will block all activities behind the box. Which means that,

in a fully loaded container, an intruder can breech the center of the

wall to remove or palace an object.

2)      During loading and unloading the container, if the container is half

filled, moving boxes will generate false alarm.

Your off to a good start (and I don't mind use of older posts - that's

what they are there for.) Now you need to detail why we choose what we

did - remember to keep it in the context of what was accomplished (100

hrs. volunteer labor, $2000 loaned/donated equipment (I'm not sure

$2000 is the correct number, I think I posted that a while back)) so

that you don't have to out-right state that a major constraint was

lack of time and money (the profs. don't want to see/hear this.)

I think it is fine to say that since a wireless ad-hoc sensor network

would be required and Tech had an on-going research project (Hutto and

Simon) with a viable product (not too expensive, proven, supported)

where we could go for advice and loan of equipment, that Xbow was

choosen to facilitate spending more time on the more difficult problem

of the analog sensors, building the demo, etc.

I'll have some edits of what you have before too late this evening.

Charlie

whats your number

I was going to call you to give the room ph#

endrias

PS. I had started to write this e-mail this morning but never sent it

to you :)

Hey Endrias,

My number at home is 4-377-7716. Feel free to give me a call.

Charlie

- Show quoted text -

On 4/24/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:

> whats your number

>

> I was going to call you to give the room ph#

>

> endrias

>

> PS. I had started to write this e-mail this morning but never sent it

> to you :)

>

>

« Back to Search results

Report SpamDelete

‹ Newer 2 of 3 Older ›

Back to csmNotes