Reading carefully through the descriptions of the Wines
projects funded to date, we see the program as dominated by practice (which I like
but that's my bias) however less (but some) emphasis on core CS or theory.
Looking closely at the first words in the overviews, one sees the terms
develop/design/build/integrate/,
often. On the other hand, there are a few themes in the body of the material:
generative programming and validation
autonomic management and certification
human orgaisation and system (self) explanation
reflection, semi-autonomous management
principles for the design of pervasive systems (including context modeling and graph theory)
economics of information and incentives
reasoning on probabilistic events
But who are the CS fundamentals people engaged in the projects doing these Quite Interesting(tm)
parts of the work?
What I would suggest in Wines II is an overarching project or family of projects
that builds a comprehensive theory framework for the Wines I projects. What we do is build a
SWOT team to go in and tease out principles
from the projects - timing out to be perfect - the Wines I projects will be 1 and a bit years in so will
have hit all the real problems (the devils in the details) and it wil lbe an ideal time to
abstract out the theory and underpinnings, and re-factorise all (well most) the projects designs.
that way we get the best of both (UK) worlds.
In such a framework, I would expect various different CS fundamentals to be applied differently - just looking at
the list above, there are several different applicable modeling/checking approaches as well as programming language
and other theories (perhaps as yet un-expressed!).
If you like, what I am proposing is a Physicists approach to funding, where we pre-cook the proposals to
take the _entire_ funding of Wines II and have a cross UK agreement on who does which bits.
This is not a consipiracy as it would be a completely open process. Of course, people could renege and opt out and
so on. BUt hey, this actually would be what the GC was all about.
my 2 pence.
In missive <78252937.1118061064@[10.104.3.115]>, Ian Wakeman typed:
>>WINES Projects Overviews
>>Design implementation and Adaptation of Sensor Networks through
>>Multi-Dimensional Co-Design (Glasgow, StAndrews, Kent, Manchester)
>>Uses generative programming to adapt networking, os, hardware (FPGAs)
>>and radio. Software is to develop water quality sensor networks. Key
>>issues such as defining optimality, validating system generated
>>against hardware and against required properties, while retaining
>>decidability, and use of cost/utility functions to make choices.
>>Medical Biosensor networks (Imperial computing / biomedical
>>engineering / ee / medicine) Imperial developing new intelligent
>>(potentially) implantable biosensors Looks at using MEMs based power
>>generation. Motivated by continuous patient monitoring. Themes: Bio
>>Sensing, generic architecture, context aware BSNs. Sensors are
>>analogue to reduce power consumption. Autonomic management. Issues
>>include what level of demonstration of function, security etc can be
>>achiveved? (to some extent medical certification handled by industrial
>>partners) and balancing expoloring design space before doing rigourous
>>version.
>>Networked Embeded Models and Memories of Physical Work Activity
>>(Lancaster) To build intelligent networked artefacts, and to
>>understand organizational and human implications. Examples are in
>>handling and storage of chemical drums, and in road maintenance and
>>repair. Artifacts percieve, interpret and react to activites. Issues
>>include how to do the necessary explanation of what and why the system
>>is doing what its doing. All the problems of accountability and audit
>>trails and how to understand what infromation to trust and allow out -
>>organisational and human implications.
>>Proactive Condition Monitoring at a WindFarm
>>(Kent,Strathclyde,Stirling) How to deal with the difficult parts of
>>sensor networks, components failing, hostile environments, radio using
>>too much power, managing a large scale infrastructure etc. Design and
>>build proactive control system which is experienced based and model
>>based. Looking to build policy managed system which is semi
>>autonomous. Ideas and issues include filtering of events to make
>>monitoring / management a manageable prospect, pragmatically using
>>available technology with real industrial examples, think about theory
>>later. Reflection, feedback and uncertainty are important, decisions
>>are procative and/or reactive.
>>
>>Cityware (Bath, Imperial, UCL (Bartlett)) Theory, design principles
>>for development of pervasive systems in urban environments. Looks at
>>how this should affect the design of urban spaces, by integrating the
>>pervasive into space syntax (syntax in architecture, analysis in
>>computing) to examine the behaviour of people in an environment.
>>Discussion about the interaction of space syntax and pervasive design.
>>Short discussion about how trust works in urban environemnts (actually
>>trustworthy and percieved to be so, with spontaneous interactions,
>>physical tokens etc) This may be a level of context modelling, and it
>>is based in graph theory so converts nicely - its based on how
>>information moves (and old work on semiotics and linguistics). A key
>>issue it highlights is that interactions with people matter. Ideas
>>and plans include:
>> context infrastructure - peer to peer policy driven servers on
>> devices; user engagement - targeted studies (short term, recruited
>> participants) + logitudinal studies (30 participants, long term
>> evolving interaction) prototyping and demployment - to prove it
>> works
>>Note that equator have a rapid prototyping toolkit on sourceforge for
>>architecture.
>>Transport Monitoring by sensor networks (Cambridge) Integrate sensor
>>networks into secure pub/sub networks and middleware to facilitate
>>application development. Specifically transport monitoring, also
>>active buildings. Issues include economics of information, building
>>incentives to information sharing, extracting useful information from
>>sensed data, queries - what is happening and how can environment
>>adjust to what it senses. There seemed to be some overlap here with
>>projects above and the question of what is generic, reusable / what is
>>specific, tailored to an application was raised. Possibly generic:
>>events which update state models. Mention of a possible meeting of
>>sensor nets people to examine commonality. There may be a case for
>>reasoning on probablistic events. Should there be an association of
>>loss/delay/period with events, and an associated programmatic toolset?
>>What attempts have there been on this area before? Obvious
>>applications to sensor networks, and to event-based middleware.
>>SHEFC Research Grant SpeckNet (edinburgh, glasgow, strathclyde,
>>standrews) Device design for 5x5mm specks which can communicate over a
>>few cms, with limited power. Intention is to buy by weight and scatter
>>liberally. Some devices already available to order. Specks are
>>programmable sensors, considered unreliable (existance, communication,
>>data quality) and non-static (including more or less mobile). Forming
>>mesh network to perform collaborative processing. Key issues in
>>limited devices - focus at device / physics / chemistry level. Some
>>tool support in c and (very stripped down) java. Also work at other
>>levels including toys (duck) and simulation comparing physical thing
>>with simultated "spec" model of device.
|