As the end of this project comes closer and closer we have a better look on whether our choices we made were good or bad. We can say that the results are good before the final components are optimized in our program.
We are almost finished writing our program and until now we can already make some conclusions. Our program is running great; the use of Python was a good choice because it gives us fast a solution, namely equations and graphics. Speed was given as a disadvantage but the results are received at a fast speed rate. It also looks quit easy to read what will make it appealing for our clients to use the program because this way it has a good maintainability. The use of Fortran was in our case unnecessary and would only give us the disadvantage that it would be difficult to understand the programming lines used in the program, especially for our client. It will also be easier with Python to find documentation when the client does not understand an element of the program.
The program also needed to be constructed to evaluate and describe systems that have more than 2 degrees of freedom, this was a big requirement so that our program would have a great flexibility and could work in different cases, this is done by making use of arrays. More degrees of freedom will make the amount of elements in the array rise but the use of arrays will make the number of elements unlimited.
I think we can conclude that our program is returning what we wanted to be the result. We only have to make some final programming actions to make the program complete and ready to use and maintain.
With our program we are trying to make it possible to give a fast and effective way to clients and to the world to have a good and fast way to evaluate a certain system. This way before producing a system it can be tested in our program and this for different values for like example mass.
In this program we are using the Hamilton’s method and this is done because the equations received by using this method are the best to give a solutions to a lot of problems in the fields of physics. This method will also give a more simplified solution than when using the Lagrangian method. If we have for example a system with n degrees of freedom there will be 2n first order Hamilton equations as compared with n second order Lagrangian equations. So to summarize it, Hamilton will make it possible to describe every system with a certain amount of degrees of freedom with only first order equations. Because of this method it will be possible to get a review of the most complex systems and that will be very important for a lot of people.
The system must from the beginning be described as an enumeration of different energetic equations and will give an output of two equations to the degrees of freedom. After making these different equations it will also be easy to make a numerical analysis of the system and show the client how their complex system will behave with the given values of that system.
So with a starting point where the system is described as an enumeration of kinematic, potential and dissipation energetic formulas, a picture of one system can be received. The relevance of this method is that every system, regardless its complexity can be derived to a list of first order equations and a numerical analysis will give a good vision on how the system will behave.
To conclude, a brief summary of the advantages/disadvantages of lateral flow (LF) immunoassays:
Advantages:
- Established mature technology
- Relative ease of manufacture – equipment and processes already developed and available
- Easily scalable to high-volume production
- Stable – shelf-lives of 12–24 months often without refrigeration
- Ease of use: minimal operator-dependent steps and interpretation
- Can handle small volumes of multiple sample types
- Can be integrated with onboard electronics, reader systems, and information systems
- Can have high sensitivity, specificity, good stability
- Relatively low cost and short timeline for development and approval
- Market presence and acceptance – minimal education required for users and regulators
Disadvantages:
- Unclear patent situation
- Miniaturization of sample volume requirements below microliter level
- Multiplexing: simultaneous analysis of multiple markers difficult
- Integration with onboard electronics and built-in QC functions challenging
- Sensitivity issues in some systems
- Test-to-test reproducibility challenging – limits applications in quantitative systems4
Literature: Raphael C. Wong l Harley Y. Tse, Lateral Flow Immunoassay, Springer, ISBN: 978-1-58829-908-6
Although clinical diagnostics being the biggest market in lateral flow (LF) tests, LF- based tests are also used in other areas. An overview:
Veterinary medicine
LF tests can be used in veterinary medicine to test commercial livestock and household pets for a variety of medical conditions (bacterial and viral infections, allergies, fertility issues, diabetes).
Examples of common tests for household pets:
-anemia
-canine adenovirus, adenovirus, rabies
-parasites such as roundworm and Lyme disease
Food and beverage industry
Food safety issues have led to more stringent legislation in food safety requirements. This has lead to an increased demand for pathogen and toxin tests in every segment of the food production industry. A driver in the demand for rapid and LF tests in food production is the adoption of Hazard Analysis and Critical Control Points (HACCP) regulations that prescribe test procedures throughout the manufacturing process. The tests are used primarily for testing raw materials, interim products in the manufacturing process and final products.
Examples of available tests for final product testing:
-Salmonella, Listeria and E.coli dipstick LF tests
Pharmaceutical industry
Product safety is a major concern in the production of pharmaceuticals, medical biologicals, and personal care products. Most Pharma products are manufactured with a long shelf- life (sometimes a year or more). If they are contaminated with slow growing bacteria, yeasts and molds, this has little consequence early in a product’s shelf-life, but can influence products quality once they have grown.
Environmental Remediation and water testing
Because of the significant impact that contamination can have on public health, most testing is performed in certified laboratories by approved methods. The LF market in this area is thus rather small. Still, these tests can be used by households to verify the cleanliness of well water.
Biowarfare
LF tests are also available and in development for biowarfare agents and pathogens such as anthrax, smallpox, avianinfluenza, and other potential biological weapons
Weblink Bacillus anthracis (spore) Lateral Flow Screening Assay:
http://www.nhdiag.com/anthrax.shtml
Literature: Raphael C. Wong l Harley Y. Tse, Lateral Flow Immunoassay, Springer, ISBN: 978-1-58829-908-6
To conclude our blog posting we will try to convince you one last time of the usefulness of Wireless Sensor Networks. This post is based on an article that appeared only two days ago on the website of “Wireless Sensor Networks Research Group”.
The picture below shows a beautiful infographic of a nearby future Smart World, comprising Smart Cities, Internet of Things and other sensing applications.
It is based on the earlier appeared document “50 Sensor Applications for a Smarter World”. You can view the document via the link below. I’d say have a quick look. It has a lot of pictures so it will only take 1 – 2 minutes and you’ll be amazed by all the existing applications. They go from studying water quality, waste management and even up to fall detection for the elderly people.
http://www.libelium.com/top_50_iot_sensor_applications_ranking/pdf
Patent Considerations
Commercializing a lateral flow immunoassay device requires special attention to regulatory issues. Neglecting these issues may prevent the device from being marketed, no matter how good the product is. Prior to research and development of a lateral flow immunoassay, patent search of all relevant prior art should be done. As a start, the following databases can be consulted: Database of the US Patent and Trademark Office (PTO), the European Patent Office database (EPO).
According to PTO, there are three types of patents: utility, design and plant. As a medical device, the lateral flow immunoassay involves the utility and design patents and not the plant patents.
- Utility patents are proprietary matters related to process, machine of article of manufacture, or composition of matter. They also include new and useful pertinent improvements.
- Design patents are related to new, original design for an article that can be manufactured.
In the field of lateral flow immunoassay, a lot of patents do exist that cover the technologies, formats, and raw materials being used in the engineering and manufacturing of the assay. Since lawsuits are very common in this field, the patent literature should be thoroughly reviewed to prevent possible legal problems after product launch.
Patent history of the lateral flow immunoassay
In 1987 (within several months of each other), three researchers filed US patents for what is now considered the basics of the lateral flow (LF) technology. All three patents did essentially the same thing with slight variations. The aim was to develop an easy OTC platform for the pregnancy test. Because of these almost similtaneous patents, it took 10 years for the patents to be issued. This 10 year delay impeded innovation while demand for rapid tests was expanding. The result is that for a long time, all LF tests were just about the same (same analytes and same technology). The three base patents expired between 2006 and 2013, inspiring a wealth of innovation that can be put in the LF format.
Literature: Raphael C. Wong l Harley Y. Tse, Lateral Flow Immunoassay, Springer, ISBN: 978-1-58829-908-6
Websites:
US Patent and Trademark Office (PTO): http://www.uspto.gov/
European Patent Office database (EPO): http://www.epo.org/
To choose the right software is important because it gives us a good foundation for the program we are creating and gives the client also the best opportunities. We began with a broad assortment of different programs but finally we ended up with software named Python, this because of its aspects, after which we could start to program. But why did we take it?
To start programming we had to choose the right software, the two options who seemed the best and that are used the most were Python and Fortran. Python, which uses an interpreted language, is described as “a remarkably powerful dynamic language that is used in a wide variety of application domains” (Python.org). When we took a look at the programming style of this language, it was recognizable because it reminded us of Java and therefore looked interesting. This software can be downloaded free, which makes it possible for everyone to use it and this is improved by the fact that it can run on different platforms like Windows, Linux and Mac.
Besides those two advantages Python gives us a lot more, the most important one is that a program written in Python is easy to read and easy to maintain because of its natural expressions. This is very important because this way all clients who want to use this program can easily make some adaptations as one pleases. This readability is also made easier because writing something in Python will be shorter than when written in Fortran. The writing in Python is also simplified by the use of modules that you can call in. These modules are libraries that for example contain the cosinus, sinus, … The last reason why Python looked good to use is because it is more often used for graphical user interfaces and this could give an extra touch.
A second programming language is Fortran that is a high level programming language that is very powerful when it comes to numerical tasks. The big advantage of this language is that it is very fast and can be a lot faster than Python, so it is possible to run more complex programs. We wanted to know if this would be a problem in our case but we found out that in Python we could make use of numerical libraries that would improve the speed of our program. We also looked at a program in Python that had a similar complexity as our program would be and there was no noticeable delay. This gave us the full motivation to try to write our program in Python. Fortran is also a language that isn’t free.
To conclude we are writing our program in Python because it had advantages for our clients and for us. For our clients it is a language in which they can maintain the program because of the good readability and because it works on different platforms. We can also make a good and attractive graphical interface because Python is often used for this. For us this is a language that would be not too complicated to write in, this firstly of all because it reminded us of Java. And last but not least we expect the speed to be high enough and will not have a negative effect on our program.
Since i’m evaluating a point- of -care device based on lateral flow (LF) technology, it’s interesting to look at the market trends in this technology.
The LF format is so versatile that manufacturers of rapid immunoassay tests have developed LF tests for almost any situation where a rapid test is required.
The world market for LF- based tests is estimated at $3652 million in 2012. (This estimates includes LF tests used in human and veterinary medicine, food and beverage manufacturing, pharmaceutical, and water utilities.)
However, growth in LF testing is derived mainly from the clinical sectors. The clinical test segment is the biggest LF- test segment and generally seen as the most lucrative. Worldwide, there is a huge demand for decentralized availability of diagnostic tests. Therefore, clinical LF- tests are used primarily to replace lab- based immunoassays in decentralized testing locations, known as point -of- care testing (POC)
The US market accounts for 50 % and the European market for 40 % of the worldwide market for LF clinical tests. Japan and Asia represents only 5 % of the market. This seems quite surprising, but has a good explanation. The healthcare system in these countries is highly centralized, not leaving much room for POC testing in the physician office or at home.
The United States has an enormous impact on how rapid test industry develops. Managed care’s obsession with cost reductions is pushing the need for nearer the patient and decentralized testing (in the home, at the bedside and in the physician’s office). However, the European market for POC tests has been growing faster than that of the United States. The EU governments have begun placing greater emphasis on the prediction and prevention of disease through more proactive diagnostics. They want to control the cost of delivering healthcare to their aging populations.
Market opportunities are also evolving in other parts of the world. Emerging markets such as South America, Russia and parts of Africa are not longer ingnored. Companies are beginning to take advantage of them, more as a method of survival than for altruistic reasons.
For our interview we had the chance to talk to Jef Mariën who is a PhD student at the KUL and has done some work on WSN’s and on network security.
Since the interview was in Dutch, here follows a translation:
To which extent is zigbee safe enough to carry sensitive data?
Zigbee uses AES encryption. This is the same encryption standard as used by a lot of web banking websites. Standard zigbee uses 128bit, which is considered more then just safe, so it is safe enough to transport sensitive data.
Is it advisable to use zigbee to grant access to buildings?
The problem with such functionality is not the safety of the encryption standard, but how safe your protocol is and how good the key is managed. Just like with a physical key and a lock. Analogous:
* if you leave the key lying around, the lock is not safe because everyone can copy the key.
* is your lock not build decently, this could be a lock of the toughest material, it will not be safe.
Zigbee for instance doesn’t provide protection against replay attacks. In these attacks, the attacker resends packets sent by you. Zigbee will see this as a valid packet and deliver it at the right application. If this packet opens the door then this can cause trouble.
A second problem is that also the managing of the encryption keys can be difficult. Zigbee has some support for key management and identity management. It only allows to send encrypted messages but it assumes pre-installed keys. This can give problems when adding new devices. For these kinds of applications you need to be sure that this entire key management
system is secure, so that you can open the door in a safe way.
For extra information on zigbee security, you can look at this presentation: http://docs.zigbee.org/zigbee-docs/dcn/09-5378.pdf
Do you no alternative protocols, safer then zigbee for secured WSNs?
At the moment I am doing research into these protocols and management systems. There are not many established industrial protocols for wireless sensor networks. There is research being done to the use of for instance SSL on sensor nodes. If you sensors could set up these kinds of connections it is advised to do so.
The development of a secure protocol is far from easy, and even standardized protocols and implementations sometimes have backdoors and troubles.
Do the low cost and slower hardware pose big limits on encryption?
This depends on the form of encryption. The zigbee hardware is more then strong enough to execute symmetrical encryption protocols like AES. However when you want to work with certificates (asymmetrical encryption), then the hardware might be to weak.
What do you think about the cost of WSNs in general in comparison to their wired counterparts?
To be honest I have no idea. I presume (!!) that wired solutions will always be more expensive to add later on, because for wired solutions it is always necessary to lay down (protected) wiring and connections.
The cost of WSNs at the moment is always relatively low, and this will probably even drop for low-end microprocessors, so I think (!!) that it’s financially interesting. I do, however, have never seen prices for this, nor looked them up. So this is a assumption.
What are your general experiences related to the reliability of a zigbee network?
I myself don’t really use a zigbee network but rather a IEEE 802.15.4 network. This is the mac layer where zigbee also builds on top of. Also my experience is limited to the use of 2 types of sensor nodes (avr-zigduino and avr-raven). I can tell you that a lot depends on the quality of the radio, strength of the signal, environmental noise and the number of transmitted packets. With a high number of packets in a noisy environment the reliability of my network drops quickly. However, I have never done tests, so this is just a feeling. I have no number to support this. It is however a generally accepted premise in the domain of sensor networks that the communication can be unreliable.
The fact is that my gateway radio is of relatively poor quality with poor drivers. Since my goals is not to deliver and industrial product, but rather produce a prototype, this is not a real concern for me.
I do however know a company that uses zigbee to secure expensive paintings in museums (MoNet from http://www.sownet.nl). This is a relatively crucial application, so I think that they have a high reliability with their available hardware.
I’d advise you to test your own hardware to see how good/bad your own hardware is.
Do you know about problems with zigbee/wifi interference?
I know that zigbee and wifi use the same frequency bands, and zigbee is typically suppressed by the power of wifi signals. I again have relatively little experience on the subject, since my work focused on the MAC/network layer of WSNs.
By coincidence I saw a paper about this topic on my last conference :
Coexistence Aware Clear Channel Assessment: Implementation of a cross technology CCA on an FPGA SDR platform
Peter De Valck (Ghent University, Belgium); Lieven Tytgat (University Ghent, Belgium); Ingrid Moerman (Ghent University – IBBT, Belgium); Piet Demeester (Ghent University, Belgium), EWSN 2013, Ghent
This was the entire interview. We would like to thank Jef Mariën for his detailed answers and easy to understand explanations.
To clarify his answers some more I will explain some terminology:
- AES encryption: It is a symmetric-key algorithm to encode data. This means that sender and receiver have the same key. Zigbee uses 128 bit keys. The longer the key, the longer encryption and decryption takes. If you don’t know the key you can’t easily decode the message. So it’s important to keep the key secured. In zigbee the key is stored in the nodes so in theory you could read it out. In professional applications reading is probably made impossible after the product has been launched. The reason replay attacks work is that you never decode anything. You just guess that a certain message you captures opens a door (since it occurred at the same time you saw some open a door for instance), and you send that same message out when you want to open that door.
- SSL: Widely used on the Internet is a lot more complicated. All logins on websites use SSL in the form of HTTPS. It uses message authentication codes to ensure integrity and authenticity of the messages sent. So no replay attacks should be possible. I looked it up and our zigbee’s only support the lowest level of security, so no asynchronous protocols.
- Zigbee vs IEEE 802.15.4: All communication protocols have different layers. IEEE 802.15.4 consist of the bottom 2 layers of the OSI model. This means that IEEE 802.15.4 only defines the lowest levels of communication. Zigbee builds on top of IEEE 802.15.4 and also takes care of the routing of packages and other high level management. But Zigbee uses IEEE 802.15.4 for the bottom 2 layers. Often the bottom 2 layers are adopted but they chose to make different top level layers. Reasons can be that you don’t have the necessary hardware to do these extra computations, if you don’t need routing and only care about points to points connections then you might not want to use the entire Zigbee stack.
From this interview we can conclude that even more critical applications like security can be supported by zigbee but that you might have to tweak your implementation here and there. As Jef also presumes, we think that in existing structures wireless solutions will be cheaper then wired solutions. However when nothing is present yet it might be worth looking at the cost of wired sensor solutions. Take into account that extending wired solutions after they have been build can also ask for extra cabling. The cost for zigbee’s are about 25 euros as a consumer. Industrialized versions will be a lot cheaper. The real cost in WSN’s are the sensors and all the extra hardware.
The hardware needed for a WSN will also become cheaper in the following years whereas cabling will not (just think about the prices of copper).
As for interference with wifi we also found another paper (http://docs.zigbee.org/zigbee-docs/dcn/08-4846.pdf) that concludes that in theory a problem can arise but in practice maybe the latency of the zigbee network may increase. So no packets are lost due to the presence of wifi. Only when the strength of the wifi signals exceeds what is achievable or available today, errors can occur. As a result they don’t see wifi as an obstacle to zigbee.
Taking all this into account we couldn’t find any reason not to go for a WSN using zigbee when you are talking about low data rates, as is usually the case with WSN’s.
In a previous post, I discussed the importance of plastic waste in the world, but especially in the oceans. I just found something that could change all of that.
A 19 year old boy, named Boyan Slat, developed a technology that could get 7.250.000 ton of plastic waste from the oceans. This technology isn’t only good for the environment, it is also very profitable.
This construction acts like a gigantic funnel that drives the plastic in the direction of the vessel, where it is divided from the plankton, filtered and storaged for recycling.
Group T Thesis, Group 1316 