Archive

Archive for the ‘Examples’ Category

Math for system designers

April 27, 2011 Leave a comment

It is very common to start system design by first solving for key design parameters in an expression that describes the target system, inserting physical constants into that solution to find suitable design scales, select parameter values with unit and tolerance, and finally analyzing the stability of the solution using confidence intervals. Traditionally this requires usage of multiple tools with limited features and therefore is both time-consuming and risky. With quflow tools, it becomes much more easy – a few lines of Python code does it all.

Below is an example within nano-electronics: What charging energy margin does a 10% capacitor designed for >99% production yield have, when designed for tunneling blockade at room temperature?

[python]
>>> from quflow import System, Symbol, constants, K, F, eV, array, std, confidence
>>> charging = System(‘E == (n – C V/e)^2 e^2/(2 C)’); charging.E
-V*e*n + 0.5*C*V**2 + 0.5*e**2*n**2/C
>>> E = charging.E(V=0); E
0.5*e**2*n**2/C
>>> blockade = System( (E(n=1) – E(n=0)) – Symbol(‘dE’), constants )
>>> kT = constants.k*array([ 300, 600, 900 ])*K
>>> C = blockade.C(dE = kT).rescale(F); C
array([ 3.09874425e-18, 1.54937213e-18, 1.03291475e-18]) * F
>>> C0 = confidence( std( 1, .1 )*1e-18*F, 0.99 ); C0
array([ 7.42417069e-19, 1.25758293e-18]) * F
>>> blockade( C = C0.max(), dE = kT ).rescale(eV)
array([ 0.0378486 , 0.01199657, -0.01385546]) * eV
[/python]

Binning:

[python]
>>> decades = grid*10 – 10
>>> for n, i in decades(array([1, 3.14, 42])):
… print n, ‘in decade’, i, ‘%g..%g’% tuple(decades[i:i+2])
2 in decade 1 0..10
1 in decade 5 40..50
[/python]

Slicing – the Matlab/numpy way:

[python]
>>> tuple(grid[0:110:10])
(0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100)
[/python]

Slicing – by template:

[python]
>>> tuple(grid[0, 10, …, 100])
(0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100)
[/python]

Combining with a unit:

[python]
>>> for x in (100 + grid[-10,-5,…,10])*units.nm: print x,
90.0 nm 95.0 nm 100.0 nm 105.0 nm 110.0 nm
[/python]

Conversion from symbolic to numeric units, with support for default units and formats.

[python]
>>> from quantities import nm, m, F, UnitQuantity
>>> aF = UnitQuantity( ‘attofarad’, 1e-18*F, symbol = ‘aF’ )
>>> default.set_units_and_formats(nm, aF, aF/nm, ‘%.2f’)
>>> (10*aF).simplified
array(1.0000000000000003e-35) * s**4*A**2/(kg*nm**2)
>>> default.rescale(_)
array(10.0) * aF
>>> print default.format(_), default.symquantity(_.units)
10.00 aF
[/python]

Sorting array result in increasing order, cut to a certain ‘range’ and/or ‘size’ if specified.

Example: First spin-degenerate states in a flat nanoelectron loop.

[python]
>>> from quantities.constants import e, m_e
>>> from quantities import nm, eV, UnitQuantity
>>> from statistics import independent
>>> default.set_units_and_formats( eV, ‘%.4f’ )
>>> Eml = Spectrum( ‘Em + El’, constants,
… Em = System(‘(m + 0.5)^2 h^2/(8 M w^2)’),
… El = System(‘((l – A B q/h)^2 + 1/4) h^2/(8 pi M A)’),
… q = -e, M = m_e, m = grid[0,1,…], l = grid[…,-1,0,1,…],
… s = (0.5,-0.5) )
>>> print Eml( w = 20*nm, A = 1000*nm**2, B = 0 )
Em El m l
# eV eV eV # #
0 0.0003 0.0002 0.0000 0 0
1 0.0004 0.0002 0.0001 0 -1
2 0.0004 0.0002 0.0001 0 1
3 0.0007 0.0002 0.0005 0 -2
4 0.0007 0.0002 0.0005 0 2
5 0.0013 0.0002 0.0011 0 -3
6 0.0013 0.0002 0.0011 0 3
7 0.0021 0.0021 0.0000 1 0
8 0.0022 0.0002 0.0019 0 -4
9 0.0022 0.0002 0.0019 0 4
>>> print array(zip( Eml.m, Eml.l ))
[[ 0 0]
[ 0 -1]
[ 0 1]
[ 0 -2]
[ 0 2]
[ 0 -3]
[ 0 3]
[ 1 0]
[ 0 -4]
[ 0 4]]
[/python]

Advertisements
Categories: Examples

Design optimization of coupled systems

November 22, 2010 1 comment

Quflow has experience from training and optimization of neural networks for human factor modeling, with surprisingly good results (http://quflow.com/publications). Recently, Fang et al. (http://tr.ietejournals.org/text.asp?2010/27/4/336/64601) listed how similar Quantum Particle Swarm Optimization (QPSO) methods has been used to successfully optimize global system performance in many engineering disciplines.

Nowadays, optimization is often integrated and relatively easy to use in most design tools. Designers can therefore focus more on analyzing which parameters matter most and let the tool do its job finding a global optimum configuration. This works well within each specific design discipline, however a complete product requires optimization across multiple disciplines simultaneously, and few tools, engineers and application examples exist for this. It would be interesting to see how such products would look like – probably much more organic and chaotic than we are used to, as in the 100% computer-generated WiFi antenna pattern below (from the last reference below) which works very well but raises questions on how it actually works. Optimization is fun, creative and easily leads to completely new ideas and understandings – very much Quflow.

Fragmented WiFi antenna

Categories: Examples, Research

Dividing risks = multiplying opportunities

November 8, 2010 1 comment

Baldwin & Woodard (http://www.hbs.edu/research/pdf/09-034.pdf) argue that the fundamental architecture behind all platforms is the partitioning into a set of “core” components with low variety and a complementary set of “peripheral” components with high variety. This achieves economies of scale while reducing the cost of creating a wide variety of complementary components.

Quflow has experience from products that are developed as monolithic designs as well as products that are designed as more generic platforms. The differences are very big. Monolithic designs may appear mature in the beginning but has a jittery quality progress and are difficult to finish, while the partitioned designs always reach and exceed expectations at a fast and steady pace.
Example: The monolithic part to the left in the illustration below did not reach desired quality and project cost targets due to a very jittery quality progress. To the right is the same subsystem in a later product where the risks were considered higher and design responsibilities were more divided.

Monolithic compared to partitioned system

As could have been expected, the quality in the latter product grew very quickly due to proper hardware partitioning and exceeded all expectations at a fraction of the project cost compared to the monolithic design. In fact it was so agile that one of the sub-teams actually took the opportunity to configure in a chipset from the next product generation, contributing to the success of later products as well!

Product quality growth

Usually the argument for not partitioning a product by its design risks is that the partitioning itself introduces risk, cost and size, but nowadays when interfacing components can be very small, cheap and generic, it seldom matters even if partitioning is kept also in the final product. Such products are also very easy to use as platform for further developments and new opportunities. All really successful products create their own unique ecosphere for further developments, and Quflow does systems engineering that makes it very easy to achieve.

Categories: Examples, Research

Receiving satellite signals

September 15, 2010 1 comment

Watson et al. (http://plan.geomatics.ucalgary.ca/papers/watson%20et%20al_ion%20navigation_winter06.pdf) analyzed what matters most when receiving GPS signals in-door. The GPS system was not designed for this but with good antennas, modern receivers and long integration times it is possible. Their graph below shows signal strengths from different satellites plotted on a hemisphere circle. The result indicates that reflections within the building are not picked up – only the attenuated “line-of-sight” direction reaches the antenna. Another interesting conclusion from their study is that besides an antenna that picks up signals from the horizon well, it is only the quality of the clock signal that matters (assuming the receive chain is a typically good one of course).

Fig. 13–Mean Tube Fades vs. Building Geometry

Fig. 3–Tube Antenna Location

The Sony Ericsson Equinox phone (http://www.sonyericsson.com/cws/support/phones/topic/locationservices/equinox?cc=us&lc=en) is a good example that integrated antenna and clocking well. It obtained the best ever GPS availability when operators tested it in field, and was implemented according to new A-GPS integration guidelines (authored by Joakim Pettersson, founder of Quflow) that in detail explains how to stabilize antenna and clocking also in very small mechanics.

Sony Ericsson Equinox

Categories: Examples, Research

Interoperability

September 14, 2010 1 comment

Working with multiple connected systems is complicated in other tools and therefore often not prioritized, leading to poor interoperability and user complaints. With quflow, interoperability testing is much easier:

1. Start a server for workspaces on one system. In this example the server publishes a phone (‘serverPhone=phone’) and its protocol on all workspaces so that other devices can use it during experiments.

[python]
>>> from quflow import Driver, Workspaces
>>> protocol = dict(
… commands = dict(
… attention="AT",call="ATD%s", answer="H1", hangup="H0"),
… events = dict(
… ok="OK", receiving="INCOMING CALL %s",
… connected="CONNECTED", disconnected="DISCONNECTED"),
… expectEcho = True)
>>> phone = Driver("COM5", number="+17654321", ** protocol)
>>> workspaces = Workspaces(protocol = protocol, serverPhone = phone)
Service spiro://:9091/<workspace> started.
>>>
[/python]

2. Control the experiment from a client system. In this case one that is connected to another phone on COM7. The printouts show communication to and from the COM ports (using their VISA resource name equivalents) when a test scenario is created and tested. Printouts in brackets indicate messages that are pending – these are programmed into the scenario as events on the line after.

[python highlight=”29″]
>>> from quflow import Driver, Workspace, enter, exit
>>> call_test = Workspace(‘localhost/call_1’)
>>> myPhone = Driver("COM7", number = ‘+12345678’, ** call_test.protocol)
>>> enter(call_test) # start a manual experiment
>>> myPhone.call(serverPhone.number)
ASRL7::INSTR> ATD+17654321
ASRL7::INSTR< ATD+17654321
(ASRL5::INSTR< INCOMING CALL +12345678)
>>> serverPhone.receiving(myPhone.number)
ASRL5::INSTR< INCOMING CALL +12345678
>>> serverPhone.answer()
ASRL5::INSTR> H1
ASRL5::INSTR< H1
(ASRL5::INSTR< CONNECTED)
(ASRL7::INSTR< CONNECTED)
>>> serverPhone.connected() and myPhone.connected()
ASRL5::INSTR< CONNECTED
ASRL7::INSTR< CONNECTED
>>> serverPhone.hangup() and myPhone.hangup()
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL7::INSTR> H0
ASRL7::INSTR< H0
(ASRL5::INSTR< DISCONNECTED)
(ASRL7::INSTR< DISCONNECTED)
>>> serverPhone.disconnected() and myPhone.disconnected()
ASRL5::INSTR< DISCONNECTED
ASRL7::INSTR< DISCONNECTED
>>> verdict("OK – myPhone *could* initiate a call with serverPhone")
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
>>> exit(call_test) # finish the experiment
>>>
[/python]

The highlighted verdict line above is automatically converted into a static test purpose (where “OK – (dut) *could* (action)” becomes “Can (dut) (action)?”) and a dynamic test status that depends on the outcome of the latest run (“OK – (dut) *could* (action).” or “FAIL – (dut) *could not* (action).”). To make it re-run after an inconclusive failure, catch the bad situation once:

[python]
>>> call_test() # Re-run the test
TEST: Can myPhone initiate a call with serverPhone?
ASRL7::INSTR> ATD+17654321
ASRL7::INSTR< ATD+17654321
(ASRL7::INSTR< BUSY)
VERDICT: FAIL – myPhone *could not* initiate a call with serverPhone.
REASON: (‘ASRL7::INSTR< BUSY’) when expecting ‘ASRL5::INSTR< CONNECTED’ and ‘ASRL7::INSTR< CONNECTED’.
‘FAIL – myPhone *could not* initiate a call with serverPhone.’
>>> call_test("ServerPhone was buzy – trying again")
STATUS: ServerPhone was buzy – trying again.
TEST: Can myPhone initiate a call with serverPhone?
ASRL3::INSTR> ATD+17654321
ASRL3::INSTR< ATD+17654321
ASRL5::INSTR< INCOMING CALL +12345678
ASRL5::INSTR> H1
ASRL5::INSTR< H1
ASRL5::INSTR< CONNECTED
ASRL3::INSTR< CONNECTED
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL3::INSTR> H0
ASRL3::INSTR< H0
ASRL5::INSTR< DISCONNECTED
ASRL3::INSTR< DISCONNECTED
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
‘OK – myPhone *could* initiate a call with serverPhone.’
>>>
[/python]

3. Run the experiment again, this time on the target system. If the target is a device tested in high volume production this is done in a separate thread within a pre-compiled boot script so that it consumes as little resources as possible and can run other tests in parallel, and with logging enabled so that any error messages can be used to document the reason for repair decisions and corrective actions.

[python]
>>> from quflow import Driver, Workspace
>>> from myplatform import myPhone
>>> call_test = Workspace(‘workspaces.myfactory.net/call_1’)
>>> call_test()
TEST: Can myPhone initiate a call with serverPhone?
ASRL3::INSTR> ATD+17654321
ASRL3::INSTR< ATD+17654321
ASRL5::INSTR< INCOMING CALL +12345678
ASRL5::INSTR> H1
ASRL5::INSTR< H1
ASRL5::INSTR< CONNECTED
ASRL3::INSTR< CONNECTED
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL3::INSTR> H0
ASRL3::INSTR< H0
ASRL5::INSTR< DISCONNECTED
ASRL3::INSTR< DISCONNECTED
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
‘OK – myPhone *could* initiate a call with serverPhone.’
>>>
[/python]

Categories: Examples, Tools

Solving the difficult system integration problems

August 6, 2010 1 comment

Integration of mobile technologies is becoming easier and faster every year. However, new problems arise and old problems occur again when devices are industrialized and tested in field. For instance, integrating a positioning sensor based on GPS/Glonass into a small device requires careful study of many aspects at the same time, such as:

  1. Environments: indoor/car/street/open air.
  2. Antenna: directivity pattern, band stability, noise rejection (in all use cases!).
  3. Electronics: noise parameters, thermal stability, clocking accuracy.
  4. Requirements: responsiveness, accuracy, energy consumption (in all environments!).

Although each separate component is working as expected, after their integration into a commercial product, the total system performance can easily fall outside specified product requirements and user expectations. Proper systems engineering skills such as making the most efficient product partitioningknowing what matters most during integration and understanding how to test the most important use-cases is even more crucial.

To make a successful product, each problem area needs to be understood in detail so that its design assumptions are quantifiable and the complete system design can be optimized well. Quflow helps small business/lean projects with the systems analysis, integration and industrialization needed to make the most successful mobile devices and new technologies.

Categories: Examples