Postings tagged with 'Engineering', listed in descending order by creation date. All Postings shown.
I often say that my work is basically, most of the time, actually: Reverse
engineering, finding out how stuff works, deciphering blackboxes. I refer to
both software and physical systems - hydraulics - and to anything in between,
control units and their logic.
Even when I was a supposed technical experts for certain (software) products
what I actually did was to reverse engineer the product in question - the
weekend before I demonstrated my consulting capabilities, allegedly backed up by
thorough training and long-term exposure.
So I think it is worth to ponder a bit on what it means to reverse
Good-enough approach (80-20-style). I had enjoyed reverse
engineering because it was different to my former life as an academic scientist.
You do not need a complete theory and unassailable arguments to explain to your
knowledgable peers about what goes on exactly in the blackbox. You just need to
know enough to track down and solve the problem a real human being actually
has. That human being might as well be yourself.
I remember the first times I solved computer problems of small business
owners - based on hardly any experience and know-how, by my current standards.
However, after years of exposure you might as well write an in-depth paper, but
you are not forced to present your know-how in this way. You primary mode of
operations is to solve problems, not to gain recognition.
Depth and breadth. It may be fashionable to say that reverse
engineering certainly requires to think outside the box, and the 80-20 statement
seems to imply that you don't need to bother to learn any 'theory' before
embarking on a debugging venture. But if you want to become really good at
troubleshooting, you better also learn the fundamentals and find a niche(s) you
want to specialize in.
You focus on your specialties where you have both deep know-how and hands-on
experience, and you add out-of-the box ideas related to other subjects. You
stumble upon an interesting aspect and decide to learn more in depth about it. I
had specialized in public key infrastructure and digital certificates, and later
on heat pump systems and thermodynamics. However, when troubleshooting I might
also need to learn something on-the-fly about a special CAN bus networking
protocol or about heat pumps without electrical compressors.
Social engineering and no false pride. I like to work on
issues that I can solve - without the need to 'escalate an issue' to some
support organization in the background. However, I try to keep Geek Honor in
check: You do not need to re-invent anything from scratch, and you do not need
to disassemble a system in case you find the human beings who built it or at
least the documentation created by them.
Social engineering can be part of reverse engineering (both terms meant in a
benign way): I had
social engineered my way into an organization that kept insider information
like manuals or passwords, and I believe learning from your peers is an
excellent way to increase your knowledge. The challenge with learning from the
community is stay at eye level with your true'peers'. I had my share of
encounters with suckers of know-how who only want to take but had nothing to
give in return.
Against the green-field. For me, reverse engineering is
strongly tied to a culture or re-use and repair, as opposed to a culture of buy
and build from scratch. If you want to
be creative with what is available, you need to decode the things you
already have (... and after a few years of operations you might debug your own
creations, no matter how excessive your documentation was.) Knowing what your
gadgets do - your software, your heating system, your appliances - puts you in
Challenge the experts. This is closely related to the
culture of re-use: If a so-called expert, certified and radiating authority
tells you flat-out that this will definitely not work (often because
the expert is also a supplier of new stuff he wants to sell) then you can only
rely on your reverse engineering skills to prove him work.
That is perhaps the most important aspect - in our era of a growing number of
interfaces with external services, clouds etc. and where you use shiny and
well-sealed blackboxes that ought not to be reverse engineered at legal
Many years ago, The Web – which has its own category on my website here –
was an experimental playground for me. You might have guessed so, just
checking out the URL of this post.
Technologies and protocols once used for displaying static websites have
been repurposed, and HTTP(s) became the so-called Universal Firewall Bypass
protocol. We synchronize files with Dropbox or offline-cache or mailboxes.
Applications like Teamviewer or the signals from our Things (as in Internet
Of Things) poke controlled holes into our firewalls so that they are
somewhat accessible from the outside.
I have written about all of that at length elsewhere – about the
insecurity of the Internet of Things and about
Data Krakens dominating small businesses. I have had mixed feelings
about the evolution of The Web. But there is one absolutely positive
outcome: That HTTP(s) (mis-)use connection magic enables me to work in a way
I would have never envisaged 25 years ago – at the time when my most
important ‘files’ were still contained in physical folders.
I am able to work nearly remote-only, not only in IT projects. About 10
years ago I was a consultant in information security. We worked from ‘home
office’, too, although company culture often dictated that there had to be
meetings in real life. Today, I still support some long-term IT security
clients, but mainly via remote and/or asynchronous channels. When we started
our experimental heat pump side-business several years ago, my standard joke
was: Someday we will work in heat pump projects the way we work in IT
projects. And the joke became true – it actually became the default way of
working, even for clients that are within geographical reach, like a 50-70km
This list on our website explains the steps / stages of such a project –
but it’s hard to convey the spirit of a remote project properly. It sounds
way too serious. On our German blog we feature
verbatim hilarious quotes of a client / ice storage heat pump system
self-builder – translation could never do it justice.
Working remotely seems to be about technology: We need to have the tools
we have today to communicate, exchange information, to monitor and manage
systems over the internet. But it is more about culture. In IT, such tools
have already been available for a long time, yet some corporations insisted
on ‘face showing rituals’. Notably, during the economic crisis of 2008/2009
many companies worked hard to keep travel costs low and resorted to working
remotely – and later never reverted to face showing mode.
Successful remote communication is based on the skill of asynchronous
communications, e.g. on processing more than the first three lines of an
e-mail, but replying thoughtfully in nested threads. My anecdotal evidence
tells me that our typical heat pump clients have that skill – tech-savvy
geeks whose day jobs are usually tech- / IT- / engineering-related .
You need to keep politics out. As soon as that infamous ‘non-verbal
clues’ become important, remote channels might be too narrow. However, I
wonder if politics can ever be tamed properly even with heavy face showing.
My pragmatic solution is to focus on simple ‘structures of command’ – work
with one single accountable client who is in charge for his/her project and
has skin in the game. Only if you need to intermediate between ‘team
members’ and listen to ‘different sides’ you get into troubles. I have my
share of experiences – like: Clandestine meetings in which project member X
told me they considered to revolut against project manager Y – depending on
my honest opinion of Y.
Many hands-on engineering tasks are gradually being supported by remote
IT tools. I am not a first adopter of such technology – like augmented
reality glasses for engineers in power plants. My icon is an angry dinosaur
for a reason. But even I say, half-jokingly, that someday people might 3D
print our heat exchanger tubes and PVC supporting constructions, instead of
working with our traditional design documents and plans.
So at the end of 2017, I embrace The Web again and my outlook is
positive. It’s like returning to the old days – when
The Cluetrain Manifesto told us that The Internet will kill TV-like ads and
foster communications between human beings – also in business. That may
sound irrational, given the ominous power of online tracking, all for the
sake of advertizing. But anyway: The positive spirit of
remote working pioneers, like Automattic (wordpress.com) is what defines
The Web for me!
I will try to explore my relationship with IT / software / computers / computer science / software engineering or whatever the best term is to describe it. I am in a mode of looking back with content, and making small changes, learning a bit more.
As often, thinking in 'opposites' comes most natural to me:
Self-study versus formal education. The IT and software industry is young and - I believe - had originally been populated by people without a formal training in computer science as this did not yet exist as an academic discipline. The community was open to outsiders with no formal training or unrelated experience. As a former colleague with a psychology background put it: In the old times, anybody who knew how to hold a computer mouse correctly, was suddenly considered an expert.
I absorbed the hacker ethics of demonstrating your skills rather than showing off papers, and I am grateful about the surprisingly easy start I had in the late 1990s. I just put up a sign in a sense, saying Will Do Computers, and people put trust in me.
I am not 'against' formal education though. Today I enjoy catching up on computer science basics by reading classics like Structure and Interpretation of Computer Programs.
Breaking versus building things. I have been accountable for 'systems' for a long time, and I have built stuff that lasted for longer than I expected. Sometimes I feel like a COBOL programmer in the year of 2000.
But I believe what interested me most is always to find out how stuff works - which also involves breaking things. Debugging. Reverse Engineering. Troubleshooting. All this had always been useful when building things, especially when building on top of or interfacing with existing things - often semi-abandoned blackboxes. This reverse engineering mentality is what provided the connection between physics and IT for me in the first place.
It was neither the mathematical underpinnings of physics and computer science, or my alleged training in programming - I had one class Programming for physicists, using FORTRAN. It was the way an experimental physicist watches and debugs a system 'of nature', like: the growth of thin films in a vacuum chamber, from a plasma cloud generated by evaporating a ceramic target bombarded with laser pulses. Which parameter to change to find out what is the root cause or what triggers a system to change its state? How to minimize the steps to trace out the parameter space most efficiently?
Good-enough approach versus perfectionism. 80/20 or maybe 99/1. You never know or need to know anything. I remember the first time I troubleshooted a client's computer problem. I solved it. Despite knowing any details of what was going on. I am sort of embarrassed by my ignorance and proud at the same time when I look back.
In moment like this I felt the contrast between the hands-on / good-enough approach and the perfectionism I applied in my pervious (academic) life. I remember the endless cycles of refinement of academic papers. Prefixing a sentence with Tentatively, we assume,... just to be sure and not too pretentious though I was working in a narrow niche as a specialist.
But then - as a computer consultant - I simply focused on solving a client's problem in a pragmatic way. I had to think on my feet, and find the most efficient way to rule out potential root causes - using whatever approach worked best: Digging deep into a system, clever googling, or asking a colleague in the community (The latter is only an option if you are able to give back someday).
Top-down, bottom-up, or starting somewhere in the middle. I was not a typical computer nerd as a student. I had no computer in high school except a programmable calculator - where you could see one line of a BASIC program at a time. I remember I had fun with implementating of the Simplex algorithm on that device.
However, I was rather a user of systems, until I inherited (parts of) an experimental setup for measuring electrical properties of samples cooled down by liquid nitrogen and helium. I had to append the existing patchwork of software by learning Turbo Pascal on the job.
Later, I moved to the top level of the ladder of abstraction by using *shock, horror* Visual Basic for Applications, ASP, and VBScript. In am only moving down to lower levels now, finally learning C++, getting closer to assembler and thus touching the interface between hardware and software. Which is perhaps where a one should be, as a physicist.
Green-field or renovation (refactoring). I hardly ever had the chance to or wanted to develop something really from scratch. Constraints and tough limiting requirements come with an allure of their own. This applies to anything - from software to building and construction.
So I enjoy systems' archaeology, including things I have originally created myself, but not touched in a while. Again the love for debugging complements the desire to build something.
From a professionals' point of view, this is a great and useful urge to have: Usually not many people enjoy fiddling with the old stuff, painstakingly researching and migrating it. It's the opposite of having a chance to implement the last shiny tool you learned about in school or in your inhouse presentation (if you work for a software vendor).
In awe of the philosophy of fundamentals versus mundane implementation. I blogged about it recently: Joel Spolsky recommended, tongue-in-cheek, to mention that
Structure and Interpretation of Computer Programs brought you to tears - when applying for a job as a software developer.
But indeed: I have hardly attended a class or read a textbook that was at the same time so profoundly and philosophically compelling but also so useful for any programming job I was involved in right now.
Perhaps half of older internet writing reflects my craving for theses philosophical depths versus the hard truth of pragmatism that is required in a real job. At the university I had been offered to work on a project for optimizing something about fluid dynamics related to the manufacturing of plastic window frames. The Horror, after I had read Gödel, Escher, Bach and wanted to decode the universe and solve the most critical problems of humanity via science and technology.
I smile at that now, with hindsight. I found, in a very unspectacular way, that you get passionate about what you are good at and what you know in depth, not the other way round. I was able to possibly reconnect with some of my loftier aspirations, like I could say I Work In Renewable Energy. However, truth is that I simply enjoy the engineering and debugging challenge, and every mundane piece of code refverberates fundamental truths as the ones described in Gödel, Escher, Bach or Structure and Interpretation.
Sometimes I wonder why I had created a Tech category separate from an IT category. The two of them are interrelated closely as
my recent Wordpress blog post on my so-called Data Kraken had demonstrated.
I call myself the Theoretical Department of our engineering consultancy because I am mainly in charge of software development, simulations, and data analysis – related to measurement data for our heat pump system (and those of our clients).
But there is one big difference between what I call 'IT-only projects' (like my PKI-related services) or engineering projects that also involve software: 'IT' is my tag for providing software-related consulting or software engineering related to somebody else's IT system – a system whose requirements are defined by somebody else. My engineering software is built according to my own requirements. My 'Tech' projects, IT-centered as they may seem, are not primarily about IT: They are about systems using, storing, and transferring energy. IT is just a tool I use to get the job done.
All things I had ever done as an IT professional turn out to be useful, and I am learning something new nearly every day – when thinking about 'energy'. Heating systems today are part of what is called Internet of Things – so IT security is also an important aspect to consider. In 2015 I used this website to finally transition to .NET (… finally, from ASP ?), and as a spin-off I also re-developed the numerical simulations for our heat pump system in .NET – representing every component as on object. 2014 I migrated our initially only Excel-based data analysis to SQL Server, and I have improved my 'Data Kraken framework' since then, adding visualization by automated Excel plots etc.
I still work for some select 'IT-only' clients - and it seems my 'IT articles' here just constitute a series of updates about the exact extent to which I still do PKI. If the occasional data analysis question comes up, any SQL, Excel, or .NET skills might come in handy in my IT projects - like querying a certification authority's database, or using a semi-automated Excel sheet to create a Certificate Policy Statement, following the RFC. But I don't advertise myself as a SQL etc. expert; I rather think I returned to where I came from, many years ago:
When I worked as an IT consultant, I had been asked over and over: How does a physicist end up in IT? There are very different reasons: The obvious one is that as a physicist you might have picked some programming experience. I had indeed contributed to the (mess of patchy 'local-community-developed') software for automating the measurement of electrical resistance of superconducting thin films many years ago, but this was not the main reason. I was an experimental physicist so I can't claim that my work was immensely mathematical or computational (and my job as 'implemented applied cryptography' via Public Key Infrastructures was not either). The main analogy is that IT systems of sufficient complexity are as unpredictable as an experimental setup governed by lots of parameters, some of which you have not identified yet – as was the manufacturing of thin films by laser ablation. I was simply patient, perseverant, and good at troubleshooting by navigating a hyperspace of options what might have gone wrong.
This might be either boring or frustrating for non-geeks. But I believe the grunt work of maintaining and fixing software is rewarding if this is an auxiliary task, done to support the 'actual' system of interest. Mine are heat pump systems, power meters, photovoltaic generators and the like. I want to understand and optimize them and so I am willing to learn new programming languages and spend hours on troubleshooting bugs with software vendors' updates. Just as back then I learn the bare minimum of Turbo Pascal to develop software for low temperature measurements.
In 2017 I am going to focus on maintaining (and bug fixing ?) Data Kraken und ich will work on making usage and 'visualization' of the numerical simulation more and more similar to Data Kraken.
Currently, Data Kraken has the following main features:
- Documentation of the sensors and log files for different loggers (Heat pump / UVR16x2, smart meter, PV…) in an Access database - a small proto-kraken per installed system.
- Documentation of changes to sensors and log files, such as: Shuffled columns in files, modified naming conventions for files, new or replaced sensors. For example, the formerly manual reading off of the surface level of water in the water/ice tank has been replaced with an automated measurement in 2016. So the input value for calculating ice volume moved to a column in a different log file, and was measured in different time intervals.
- A Powershell script grabs all log files from their source locations, and changes date formats, decimal commas and line breaks. (I found this to be more performant than manipulating every line later after the import to SQL Server).
- The Powershell script then creates an updated set of SQL scripts – one set of scripts and one SQL database for each installation / each client. For example, the CREATE TABLE or ALTER TABLE commands are created based on the Access documentation of measured values and their change log.
- SQL scripts create or add SQL Server database fields, import only the files containing data points not imported yet, and import their data to a staging table. Each SQL database can thus always be re-created from scratch – from CSV log files and the meta documentation (Access).
- Error values are modified or deleted from the staging table, as defined before in the Access database (and such in a SQL script): For example vendor-defined error values for not connected sensors (as 9999) are set to NULL or whole rows of values are deleted if the system was e.g. subject to maintenance according to other system's documentation.
- Finally, the most important script is run: The one that does the actual calculation of e.g. average brine temperature, energy harvested by PV panels or the solar / air collector by day, or daily performance factors of the heat pump. The script needs several levels of SQL views – all of which are re-created by the script.
- Microsoft Excel is used as a front-end to show values from tables with calculation results. One Excel-formula only simple table allows for browsing through values, and picking daily, monthly, yearly, or seasonal numbers.
- Excel plots are automated with respect to the fields (columns) and to start and end date. Existing plots can be copied (also from other workbook), then documented in a table. The documentation table can then be modified and is used as input. Color and line widths are still tweaked manually.
Weird as this setup sounds, it allowed me to develop and change the solution just in the right way – installation by installation, e.g. by testing the changes to log files after the control unit's firmware for one specific installation first.
I blog about anything heat-pump-related, in particular about our system. In
addition, I am interested in thermodynamics, heat pumps and heating systems in
general - and their integration with the smart grid and related security
concerns. These are my postings about our 'ice-storage-/solar-' powered system specifically and postings on closely
related subjects like the power grid, renewable energy and sustainable living.
I am running a small
engineering consultancy together with my husband. Following Star Trek
terminology, he is Chief Engineer, and I am Science Officer.
In overly correct legalese, my job titles according to our business licences
are 1) Consulting Engineer in Applied Physics and 2) IT Consultant.
We specialize in planning of
heat pump systems with
unconventional heat sources, that is a combination of an underground water
tank and an unglazed solar collector. 'IT' means: playing with control units and
As we run a
focused on this system and I also devote
a 'sub-division' of my English blog to
it, I use this site (radices.net) mainly for consolidating resources and links -
in the same way as I curate security / PKI related links. Perhaps these link
dumps will not be very useful for anybody but myself.
I once was a laser physicist and a materials scientists - my specialties
having been high-temperature superconductors, laser-materials processing with
Excimer lasers, and the microstructure of stainless steel. Then I turned to IT
security, IT infrastructure and IT management for more than 10 years.
In 2012 I
felt the urge to reconnect with my roots as a scientist and engineer, and we
started working on our own heat pump research project in stealth mode. It turned
to a second 'branch' of our two-person business. There are connections between
my different fields of expertise - IT security and heat pumps - like: the
security of the smart grid, 'hacking critical infrastructure', monitoring and
control systems. Even the data we gather with our pilot setup have turned into
'big data' that require analysis and management.
So I am actually more of an engineer than a physicist. But I am still very
interested in theoretical physics as sort of a mental exercise, and I indulge in
reading textbooks as hobby. In 2013 I had focussed on
(re-) learning quantum field theory.
Since 2014 I am mainly blogging on down-to-earth classical mechanics or
thermodynamics, and I enjoy doing cross-checks and back-of-the-envelope
calculations on my blog.
Heat pump usage in different countries and history of heat pumps
Unusual heat sources
Sizing heat pumps - I am trying to learn the terminology of standards
commonly applied in English-speaking countries:
Power grid and availability
Hydro power plants
In Sweden the world's largest pumped hydro storage plant might be built:
- See bottom of page 30 of
this research paper:
Besides the official estimations there are
some discussions [28b] about building pumping capacity between the lakes
Vänern and Vättern in Southern Sweden. The difference in altitude is 44
meters between these lakes.?
- ... and the
last page of this presentation:
Possible future? Mariestads
Kraftverks AB & others 50 km tunnel between the lakes Vänern & Vättern Cost:
250 billion SEK. Installed capacity: 50000 MW .
Free long-term weather data
Inputdaten für eigene Simulationen.
Germany and Austria.
Climate data for the last decades. The navigation is something you need
to get used to (Pick: Cities, Climate, Climate Robot...). Therefore I start
Ice Days for Vienna. It is a bit weird that available data seem to
depend on the choice of the language (less data for Vienna in English).
The winter 1962/63 was the coldest since 250 years in Europe (German article:
Winter 1962/63 in Europa. Englisch article:
Winter of 1962–63 in the United Kingdom).
More data from a talk / slides
avaiable at the website of the Royal Meteorological Society:
The bitter winter of 1962/63 - this winter was unusually mild in Canada and
Could such a winter ever happen again? "The 1963
winter is well within the population of other cold winters that have been
experienced in this country ... It is not necessary therefore to seek some very
special cause in order to explain it." – H.C. Shellard , Meteorological
Magazine , 1968 (p.21 of PDF)
Different heating systems
Statistics for Austria:
Heating 2003 to 2012 by fuels used and heating system (in Austria). Less
than 15% of (primary) heating systems are stoves, and they have been on a
decline in the last decade.
Units, heat values, energy costs
Tools for converting units
Properties of water (for comparing the energy stored in a water / ice tank)
Costs of energy - international
Monitoring, Control, IT
Metering and monitoring electrical power consumption
- Smart meters with data loggers and/or various interface for attaching
loggers - to be installed behind the official smart meter:
- Parsing an online monitoring website is perhaps the most universal
'real-time protocol' in case not other interfaces are available. E.g. by
using Powershell, I tested with the local website of a Fronius Symo inverter
and their web portal www.solarweb.com.
One option: Start an
InternetExplorer.Application comobject and identify the html containing
the interesting value per its ID (getElementById).
Manuals of data loggers by Technische Alternative Gmbh (for control units
Bus topology. Note that UVR1611 is automatically terminated by default.
Heating with computers
Computers installed in private homes provide their computing power to cloud
services - while heating those homes.
Basics (Physics) - Mechanics, Electrodynamics
The Feynman Lectures of Physics
Volume 1: Mainly mechanics, radiation and heat.
Mainly electromagnetism and matter
... an odd combination probably.
But I have a penchant for
For me IT security, physics, and engineering are all connected naturally, and
not only through my biography.
The communication between devices making up the internet of things need to be
secured. Publicy Key Infrastructures may provide X.509 certificates needed to do
Physics provides one the one hand the underpinning of engineering, on the
other hand mathematical methods used in physics can be applied to all kinds of
complex systems. There is some truth to this satirical explanation of the
relation between Feynman diagrams, certificate validation, and hydraulic designs..
But philosophical musings aside, on a daily basis I simply like to play with
technology: Exploring how applications and systems use digital certificates and
how they can or can't be 'hacked'. How to build ('hack') a technical solution
using off-the-shelf components? How to develop a simulations tool from so-called
simple 'Office software'?
(Last Update: January 13, 2014. Created: September 14, 2013)
My motto is: Building bridges between human beings and technology.
I had always been working as a vendor-agnostic consultant and trusted advisor
to clients and I support them with picking, evaluating, understanding and implementing technology. Our business is called punktwissen:
an artificial German word made up of
'Punkt' (point) and 'Wissen' (knowledge), indicating:
Getting to the point and boiling down knowledge to the essential information.
My specialties: Modelling of heat pump systems that utilize unconventional
heat sources, troubleshooting issues with digital certificates and Public Key
My mission: Improving personal and economic independence
of small businesses and entrepreneurially
minded persons - via the clever utilization of renewable energies and carefully selected IT tools.
I am interested in the interfaces between building technology, energy
engineering, applied physics, and IT infrastructure. In my thesis (2013) I have
tried to combine everything I was ever interested in – physics, IT security,
power engineering – writing about smart metering and security.
Professional Profile |
punktwissen website |
My Blog |
punktwissen Blog (DE)