This second part continues the “home automation” project. In this post we will narrow the concept & lead the reader to a more realistic approach.

1. Plan & Design

Customer’s requirements

In France they call it “cahier des charges”. And it’s generally full of useless diagrams, descriptions, copy&paste. If you’re lucky you get a live interview with the customer. If you are half-lucky, you get some form of reply by email, stating other useless descriptions. If you are clearly not the lucky type you get just a 20-page summary.

The task is simple: plan, evaluate & calculate cost. You’re an architect, so everyone expects a quick, precise and well-documented answer.

Yet, turning the table, how would you evaluate a “home automation project” based on the following customer needs  (10 supreme requirements):

1. the project should allow everyone, using only internet access to
2. move, hear, see, measure or plan activities (just this word, “activities” nothing else is written in the famous Cahier des charges – CDC from now on) by using
3. a low cost (I adore this statement every single time), easy  to build solution
4. that will use only general available raw materials
5. require nothing special to be implemented within the existing home infrastructure
6. is future-proof and scalable
7. have a low cost of maintenance
8. require no hyper-qualified human workforce to develop (mind the price)
9. be operational in the shortest time possible (love that part also, generally yesterday is the preferred term..)
10. the developer should use the best practices, technology-proven concepts

? It does seem a little bit impossible isn’t it? The requirements are approximate (or interpretable at least – notice word like activities, low cost, everyone).

The interpretation

You start by making what I call a napkin annotation.   Let’s rephrase the customer needs:

1. the project should allow everyone entitled users, using only internet access (mobile internet, connected internet) to
2. move, hear, see, measure (have an array of sensors) or plan activities (fulfill tasks)
3. a low cost (not so expensive), easy  to build solution
4. that will use only general available raw materials
5. require nothing special to be implemented within the existing home infrastructure
6. is future-proof and scalable
7. have a low cost of maintenance
8. require no hyper-qualified human workforce to develop
9. be operational in the shortest time possible (we will use the necessary time, not a minute more, we’re not acting against the client)
10. the developer should use the best practices, technology-proven concepts (minimum R&D, refactoring if possible)

With the annotations, you need to summarize and extract the essential, in order the understand what the customer really needs. This part generally is a two-tier one and should be made independently by someone with a technical orientation in mind and by some-one who is either aware of the customers business activities (and who clearly understands his need) or by someone who is completely independent of software development at least.

The summary would be the common part of this two diverging visions. I call it “the understanding”.

The understanding

So, the “tool” should be capable of:
- giving the user a full view of his house (by moving itself as necessary)
- move items in the house as necessary (doors, dog/cat food, etc)
- integrate an array of sensors (video camera at least, other sensors as a bonus)
- should be on a reasonable budget, say 50-200Eur maximum – depending on the complexity
- construction parts should be off-the-shelf (ebay, international electronics stores, etc)
- should have a modular approach and allow the user to decide it’s precise usage at a given moment

When this phase is over an assessment is necessary. Are we capable of doing it?

Internal assessment

This phase is pretty decisive. Each project has its own adventure behind. Taking the risk (or not) is not a game for the faint-hearted or the much-too-brave ones, for obvious reasons. It’s generally a OK/KO resolution. And it’s up to you as a person to decide that.
Before starting this project I knew that:
- electronics/physics will play a major role for a part of this project
- I hate high-school physics. Too many formulas, too many nonsense for someone like me. I prefer discovering instead of learning without trying myself
- Some nights will be lost. Or in software terms: “overcooking”. You are already staffed during normal hours, so this will be on your free time.
- Motivation is the key factor. A high level is required.

After this assessment my conclusion was (in my case): OK.  I’m motivated and I want to learn. I can assess that you are also, reading all the way up to here. What’s next? R&D.

R&D

The holy grail of the geeks. Or the driving force behind human knowledge. Call it as you wish. I call it “accumulation”. We need to understand how, when and at what cost we can do things.

Let’s start with the “understanding”.

We need to move around was the requirement. Everyone knows that “motor” is the keyword. Geeks will say other things also, but we generally don’t listen to them. Ok, a motor. How big? What energy source? How will it steer?

The first thing that comes in mind is the human experience that we have concerning that subject. A remote controlled car perhaps? Remember how its clumsy steering limited its maneuverability? It took 1m at least to turn. Awful. So you start seeking ideas. A good place to start is …letsmakerobots.com for example. After some reading you learn new things:

- tracked movement (think: tank, forgive the pun) allows you to turn left/right in confined spaces.
- omni-wheels are utterly cool. And hey, there’s already a product doing some sort of home automation… Rovio. We will get later to this

The decision is: it will move around using tracks. Omni-wheels are not that cheap.

Array of sensors was the second requirement. Think a camera. Think webcam. Think again because of the wire and the requirement #1. Think wireless camera. Think cheap. Think ebay for example. Wireless camera. Yeap, that should do it for the camera. What else? Distance sensor? Nice.  After some research: Sharp makes some nice ones. Infrared. Ultrasound (another option) would disturb your cat/dog. What else? Contact switch? Yes, should be simple to implement. Anything else? Should do it for the start.

Move items. Motors? Yes. But they are a little bit imprecise. How about servos? Yes. Precision. Customers love precision. And they are of different sizes, so the “modular” approach works like a charm. We can move things with robotic arms easily. Mind the price however.  Servos in any case appear to be the solution.

Ok. Aren’t we missing some things here?

How can I pass commands? Well.. Wireless. More precise? you can have: Bluetooth, WiFi, Zigbee, RF modules, etc. After some research, Wifi is not that cheap, Zigbee is not that widespread among consumer electronics, RF modules the same. “Natural” choice? Bluetooth. Ok, but Bluetooth does not work from 2000km right? The customer wants that. Hm. Wifi neither.

Crucial choice: make the robot “internet aware” or use a “relay” (computer that sends Bluetooth commands for ex). No, you are an architect. We will allow the robot to communicate, the implementation however is not relevant to know the details. You mean an “interface“? Yes. Interface. We need to specify something that allows to send/receive and that’s all. The rest is up to the user.  From now on, this will be the “CommunicationInterface“.

Energy? Oh yes. That point. A battery? Or a DC adapter? Again, “interface”. I need a plus, a minus and that’s it. We will call that “EnergyInterface“. Similarly we have “MovementInterface”,  “SensorInterface” and “MoveItemsInterface”.

Great. Let’s recap:

• MovementInterface (lef, right, forward, backward, up down?)
• CommunicationInterface (send/receive)
• MoveItemsInterface(left, right, up, down, etc?)
• EnergyInterface(plus/minus voltage)

Yeap, sounds like a basic specification to me. That means that the R&D phase is gone. We are rapidly approaching the prototyping one.

Wait. Aren’t we missing something here? Were’s the brain? How is going to master all this Interfaces? We need some form of  orchestration here. As this brain will be on the move, the energy consumption should be low. A laptop? Hm, not exactly. A laptop is not that autonomous (think 15h maximum?) and it weights too much. Embedded users know where I’m pointing. Microcontrollers. You are seeing their work everyday. Elevators. The typical example. Day & night they do their endless loop. But wait, they are not using C# or .net at all. That is right. But they are just a piece of the puzzle. Call them the “Executors”. The real brain will be in .net. They will be just humble servants, waiting for commands. Ok, but the customer has clearly specified that non hyper-qualified workforce should be used. Microcontroller programming is not that easy. I agree, but using the microcontroller as a prepackaged command interpreter will allow the customer to focus on its usage rather than its internals. The customer will say “move forward” in his application and the microcontroller will obey. Move forward + measure distance in front + avoid obstacle is not going to be decided by the microcontroller, but by the .NET mastermind of the solution.

Hmm. That sounds complicated…. Hearing this, I generally draw Visio from the backpack and begin drawing. Here’s what I got:

Stay tuned. The next post will cover the following aspects:

- prototyping
- a real crash course in electronics
- lessons learned

Yes, it’s English. It’s English because although I live in France for a couple of years now, I still prefer this way of communicating. My sincere apologies (mes excuses as they say it) to our French readers.
So, as we’ve never been introduced, let’s get to it: Alexandru Radu, Architect, Saturneo.  Briefly: Microsoft .Net. Only.

This post is the first one (a whole lot more to follow) in a series during which I will discuss a captivating subject. More precisely “Home Automation”.

It all started way back in 2006 I think, with Bill Gates’ (remember, .Net only..) vision of a “smart home”.( More). Visions are visions, reality however is a little bit different. Moving to Paris (where rooms are ridiculously small) is not an easy task, especially if you have a dog used to chew anything that’s available in the house. One may say, ok, but it’s a technical blog, not a social life blog. Mind you, we will get there in a moment.

Let’s just acknowledge  one thing may of us are familiar with words like Wifi, Bluetooth or Ethernet. Just by reading this blog I may suggest that you clearly are. Having all this in your house is an opportunity. Just imagine that you can check if a flooding has occurred being on vacation. Or remotely checking if the envelope you were waiting for has just dropped in your postbox (the physical one, yes).  Or feeding your cat remotely. Or entertaining your dog while being away, preventing another “chewing disaster”. Or simpler: receiving an alarm trigger while on vacation (burglar, water, gas, etc). All this is feasible. Yes.

As a software developer we rarely see a software performing other tasks as “create customer”, “transfer found”, “deny access”, etc. We rarely see a physical impact of our code. Why? Because that’s general business software. ERP, CRM, etc. On rare occasions we get a  RFID/Barcode reader as a bonus. Or a RS232 sensor. But that’s about it… For general “physical use”, .NET has rarely been put to good use. Unfortunately, up to now, when we say automation, we generally mean a low-level language. ASM, C++, etc.

Things are about to change. Follow this blog and we’ll discover some opportunities on how to interface with the real environment by using .NET.

What I promise you is that:

• you will get a crash course in physics and robotics
• you will be able to interact with your home, while being 2000km away
• you will have to work hard to understand some of the points explained here
• you will get some elements for project management

Stay tuned.

Un rapide post depuis un moment, mais le dossier qui nous accapare en ce moment vient d’être sélectionné par le ministère de l’économie, de l’industrie et de l’emploi dans le cadre de l’appel à projet “Services innovants du Web” (secretariat à l’économie numerique, Nathalie Kosciusko-Morizet).

Merci à ceux qui nous aident et nous soutiennent au quotidien, merci au comité de sélection, ca fait plaisir !!!

Et oui, c’est la crise, je ne vous apprends rien. Reste que je constate opérationnellement au contact de mes clients que la crise touche beaucoup moins l’expertise !

Nous sommes sollicités de façon accrue sur des audits de code, performance, mise en place de processus, … bref, sur de l’expertise.

Qu’est ce que j’entends par “expertise” ? Le savoir faire, les manipulations pointues, les actions qui vont directement au but. Les exemples sont nombreux:

• . Corrections d’anomalies impactant les performances (fuites mémoire, ré ingénierie d’accès aux bases de données, mise en place d’indexes, utilisation des vues, procédures stockées…)
• . Audit de code pour diminution des coûts de maintenance (factorisation de code, utilisation de librairies standards plutôt que “faites main”, normes, bonnes pratiques)
• . Migration d’application vers des versions de frameworks, serveurs d’application… dont les développements sont réputés plus productifs (et d’ailleurs, qui le sont souvent), comme passage de .Net 1.1 à 3.5, de SQL Server 7 vers SQL Server 2008
• . Mise en place de cycles courts sur ces actions coups de poings (actions concrètes, rapides à mettre en œuvre et dont la mesure du résultat est immédiate): Amélioration de la performance d’une page, temps de traitement d’un batch…

Tout cela peut paraitre bateau mais les applications sont aujourd’hui plus développées par des juniors que par des seniors, je n’apprend rien à personne, et les seniors souvent plus occupés à vendre qu’à faire.

Je n’ai rien contre les juniors, dont j’ai été comme beaucoup, mais la part d’expertise  aujourd’hui est plus basse qu’il y a 10 ans et diminue… et la tendance Off shore n’est clairement pas dans le sens d’une mise en avant de compétences expertes, tout au moins au contact du client.

Je pense en effet que les experts doivent être au contact de leurs clients, qu’ils soient internes ou prestataires. Ces compétences expertes nécessitent souvent une connaissance fonctionnelle, une confrontation aux attentes (exprimées ou implicites) du client.

Or, les experts de demain sont les développeurs / concepteurs d’aujourd’hui. Les experts de demain sont ils off shore ?

Je ne le pense pas, d’autant que cette expertise, pour technique ou fonctionnelle qu’elle soit, fait souvent appel à des repères culturels, ces fameuses “attentes implicites”.

Et vous, qu’en pensez vous ?

A moi l’honneur du premier “Post”, la lourde charge d’entamer ce qui sera notre espace d’expression.

Saturneo est l’aboutissement de notre réflexion afin de lancer de nouvelles idées, projets, envies dans un projet d’entreprise.

Notre ambition est d’être reconnu par nos clients et nous mêmes comme portant les valeurs de:

• Savoir Faire
• Engagement
• Sérieux
• Créativité
• Dynamisme
• Innovation

Évidemment, ces valeurs ne sont pas décrétées mais portées par tous les collaborateurs de l’entreprise, qui se présenteront au fur et à mesure de ces post.

Ce blog n’a pas vocation a porter le communication de la société, ni même pour unique vocation de partager nos experiences professionnelles.

Ce blog sera l’occasion de partager nos centres d’intérêt, nos valeurs, nos accomplissements et nos réflexions.

C’est parti !

Julien