Applied Electromagnetic Theory
University of British Columbia
Department of Physics and Astronomy
Spring 2004
www2.eng.cam.ac.uk/~tac1000/emfieldsandwaves.htm
Ohm’s Law, the Electromotive Force, and Faraday’s
law of Induction, and mutual inductance
1.1 Ohm’s law
Background: When a marble drops in molasses, the drag it experiences is
proportional to the rate it falls (by a drag law
THE TAGGED SIGNAL MODEL
A PRELIMINARY VERSION OF A DENOTATIONAL FRAMEWORK FOR
COMPARING MODELS OF COMPUTATION
Edward A. Lee and Alberto Sangiovanni-Vincentelli
EECS, University of California, Berkeley, CA, USA 94720.
Abstract
We give a denotational framework that describes concurrent processes in very gen
references.doc:
To Be Added:
MAT1320: Calculus by Berkey
ELG2130 and ELG2135: Sadiku and add as well Rosa
? http://www.physics.umt.edu/~jacobs/Course_Materials/PH321_05/tds2014_manual.pdf
? http://www.ecs.tuwien.ac.at/lehre/Microcontroller/Docs/TDS200.pdf
http://www.seas.upenn.edu/ese/rca/instruments/HPfuncgen/WaveFormGen/WaveFormGen.html
D:\ELG2130\berkeley and D:\ELG2130\hong kong
PHY2361: Physics of... by Eisberg
Modern Physics from a to Z by James Rohlf
http://scienceworld.wolfram.com/physics/FiniteSquarePotentialWell.html
http://scienceworld.wolfram.com/physics/Half-InfiniteSquarePotentialWell.html
http://scienceworld.wolfram.com/physics/HydrogenAtom.html
http://scienceworld.wolfram.com/physics/InfiniteSquarePotentialWell.html
http://scienceworld.wolfram.com/physics/PotentialStep.html
CSI1102: http://www.cs.queensu.ca/home/cisc121/2003f/lecturenotes/mcleod/slideslistB.html
SEG2101: http://www.sintef.no/time/elb40/html/elb/sdl/sdl_t01.htm#30345
MISC: http://www.iis.ee.ethz.ch/~zimmi/publications/comp_arith_notes_l.ps.gz
http://www.engineeringforum.org/
http://www-cad.eecs.berkeley.edu/~newton/Classes/CS150sp98/lecture.htm
http://www.cs.berkeley.edu/~pattrsn/252S98/
http://www-math.mit.edu/~edelman/18.337/BOOK/master.ps
http://www.eecs.harvard.edu/~dbrooks/cs146/
http://www.dcs.ed.ac.uk/teaching/cs3/comparch/slides.html
http://www.ece.ubc.ca/~elec487/
http://www.turnerlab.biotech.ubc.ca/eece_254/index.html
http://www.ece.ubc.ca/~elec359/
CEG2131: Essentials of Computer Architecture (Hardcover)
by Douglas E. Comer
http://eca.cs.purdue.edu/CS250/ir/lec.html
SEG:
***** Embedded Software: The Works (Paperback)
by Colin Walls
***** Software Design Methods for Concurrent and Real-time Systems Gomaa
Software Design for Real-time Systems
Author: J.E. Cooling
Introduction to Real-Time Software Design by S.J. Allworth
ELG2130: http://www.ece.mcmaster.ca/~davidson/EE2CJ5/slides.html
Fundamentals of Electric Circuits
Charles Alexander, Matthew Sadiku
PHY3320: http://www.physics.ubc.ca/~janis/Courses/401/401lect.html
PHY2310: http://rsrawat.myplace.nie.edu.sg/Teaching/CAP102/CAP%20102-Lecture%20Notes.htm
http://cnx.rice.edu/content/col10279/latest/
http://optics.hanyang.ac.kr/~shsong/syllabus-AO-2004-2.html
PHY____ The Electromagnetics problem solver
QC 760.52 .E44
ELG3120:http://www.engr.usask.ca/classes/EE/351/ee351-main.html
http://dynamo.ecn.purdue.edu/~ragu/301/
ELG4132: http://www.cpe.ku.ac.th/~pom/courses/204424/2005/
http://www.cse.sc.edu/~jimdavis/Courses/2003-Fall%20CSCE%20613/F03_csce_613_lectures.htm
http://www.cs.man.ac.uk/teaching/electronics/CS221/
http://sina.sharif.edu/~hessabi/Adv_VLSI/index.html#Lecture%20Notes,%20Course%20Description,%20and%20Tentative%20Schedule
http://lsmwww.epfl.ch/Education/VLSI1-04/vlsi01_docs.html
http://appsrv.cse.cuhk.edu.hk/~ceg3490/
http://ece-classweb.ucsd.edu:16080/fall05/ece260a/lecture.notes.html
www.eie.polyu.edu.hk/~em/fdcn03pdf/Networking1.pdf
www.eie.polyu.edu.hk/~em/fdcn03pdf/Networking2.pdf
ELG4172: http://www.ee.nthu.edu.tw/~chhwang/classes/EE3660/
http://www.ece.ubc.ca/~elec466/
http://www-sigproc.eng.cam.ac.uk/~ad2/3F3.html
http://www.it-c.dk/courses/IS/F2000/download.html
digital communications: http://licos.epfl.ch/index.php?p=courses_digital2003
CEG3131: Introduction to Embedded Microcomputer Systems: Motorola 6811/6812 Simulations
Jonathan W. Valvano
CEG2151: http://www.doulos.com/knowhow/vhdl_designers_guide/
http://tisu.mit.jyu.fi/embedded/TIE341/TIE341.htm
CEG3150: http://tisu.mit.jyu.fi/embedded/TIE341/TIE341.htm
http://sunpal7.mit.edu/6.111/s2003/ (lecture notes)
Digital Systems: Principles and Applications Ronald Tocci, Neal Widmer
VHDL: Analysis and Modeling of Digital Systems Zainalabedin Navabi
CEG4161: http://www.caspur.it/risorse/softappl/doc/matlab_help/toolbox/stateflow/concep20.html#29877
CEG4153: book by C S G Lee, and book on the DH convention.
Robotics in Europe: http://www.robotics-in-europe.org/listing.php?id=16
Added:
06/21/2005
ELG2135: http://csr.phys.ualberta.ca/gingrich/teaching/phys395.pdf
http://www.phys.ualberta.ca/~gingrich/phys395/notes/phys395.html
PHY3320: Static and Dynamic Electricity by William Smythe (C/O).
CEG3131: http://www.cs.csubak.edu/~wli/Wei_Li_Tch/CS_420/LAB_420.html (68HC12 assembler)
http://almy.us/freesim.html (68HC12 simulator)
http://www.vlsilab.polito.it/~max/motorola/68hc12/docs/
CEG4392: http://www.altera.com/support/examples/exm-index.html
CEG4161: http://www.omg.org/news/meetings/workshops/RT_2003_Manual/Presentations/6-3_Kopetz.pdf
http://www.csc.uvic.ca/~csc454/notes/B.Introduction.pdf
http://www.csc.uvic.ca/~csc454/notes/C.faults.pdf
http://www.csc.uvic.ca/~csc454/notes/N.Reliability.pdf
Misc: D. Gajski, Specification and Design of Embedded Systems
Other books by Wayne Wolf
Embedded Systems Overheads, Lund University
Embedded Systems Overheads, Linkopings University
Embedded systems overheads, Swiss Federal Institute of Technology, Zurich.
Real Time Systems, Korea Advanced Institute of Science and Technology.
Added 07/13:
PHY3320: http://electron6.phys.utk.edu/phys594/Tools/e&m/summary/maxwell/maxwell.html
http://fermi.la.asu.edu/PHY531/units/
http://www.pas.rochester.edu/~dmw/phy218/Lectures.htm
Added 07/18:
Misc: http://camars.kaist.ac.kr/%7ehyoon/courses/cs440/note_index.html
Digital Arithmetic (Hardcover) by Milo D. Ercegovac, Tomás Lang
http://www.cs.ucla.edu/digital_arithmetic/viewgraphs_p.html
http://www-inst.eecs.berkeley.edu/~cs150/fa04/Calendar.htm
CEG3180: http://camars.kaist.ac.kr/%7ehyoon/courses/cs440/note_index.html
http://www.iu.hio.no/teaching/materials/MS003A/
Added 07/19:
CEG3151: http://www-inst.eecs.berkeley.edu/%7Ecs152
Added 08/09:
SEG2101: http://www.cygwin.com/mirrors.html
http://www.cygwin.com/packages/
http://www.cs.man.ac.uk/~pjj/cs211/yacc/yacc.html
http://www.cs.man.ac.uk/~pjj/cs211/lex/lex.html
CEG4153: Robot Dynamics and Control by M. Spong and M. Midyasagar
Tutorial on Robotics by C. Lee, R. Gonzalez, and K. Fu
An Introduction to Space Robotics by Alex Ellery
Added 08/17:
GNG1100: http://www.mum.tu-harburg.de/Tutorials/Start.htm
CSI1102: http://www.cs.toronto.edu/~krj/courses/108/lectures/
Added 09/04: Quaternions and Rotation sequences by Jack Kuipers
Recommendation:
http://sis.berkeley.edu/gc/curricula.html
http://www.stanford.edu/home/academics/departments.html
http://www.basetechnology.com/entnet.htm
http://www.ednmag.com/
http://subscribe.penton.com/ed/
http://www.hte.com/uconline/
http://www.hte.com/uconline/ecd/
The Microcontroller Idea Book, by Jan Axelson
Serial Port Complete, by Jan Axelson
Parallel Port Complete, by Jan Axelson
Printed Circuits Handbook, by Clyde F. Coombs
A Whack On The Side Of The Head, by Roger von Oech
EPFL courses for site profs:
Analysis III:
http://alg-geo.epfl.ch/~liebendo/
Cours d'Analyse Numérique pour Ingénieurs:
http://iacs.epfl.ch/asn/teaching/ing.html
Probabilités et Statistique I&II:
http://ima.epfl.ch/prst/enseignement/probabilites-statistique/Description.html
Cours de Physique générale III et IV:
http://irrmawww.epfl.ch/~pasquarello/physgen/physgen.html
Circuits et Systèmes I, II:
http://lanoswww.epfl.ch/studinfo/courses/cours_cas/
Search ee ethz for the names of the courses in the curriculum.
http://www.ee.ethz.ch/studium/D-ITET_DiplReg2001.pdf
Math ETHZ:
http://www.math.ethz.ch/undergraduate/lectures
Informatik I & II:
http://www.inf.ethz.ch/personal/vroth/InfIIMaVt/
Netzwerke & Schaltungen II:
http://www.ife.ee.ethz.ch/~barras/NuS2/indexNuS2.html
Theoretical Physics:
http://www.itp.phys.ethz.ch/lectures/RGP/old/SS00/
Signal- und Systemtheorie II:
http://control.ee.ethz.ch/~sigsys/
http://control.ee.ethz.ch/~sigsys/skript/Script2005.pdf
Halbleiterbauelemente:
http://www.iis.ee.ethz.ch/%7Eweb/vorlesungen/halbleiterbauelemente/downloads.html
Seen before on crypto: http://www.cs.ucsd.edu/users/mihir/papers/gb.html
quantum computing: http://www.theory.caltech.edu/people/preskill/ph229/
Math books: http://www.geocities.com/alex_stef/mylist.html
Economics: http://www.econphd.net/notes.htm
Calculus Lecture Notes: http://www.math.scar.utoronto.ca/calculus/Redbook/
Dynamical Systems: http://www.math.okstate.edu/mathdept/dynamics/lecnotes/lecnotes.html
Linear Algebra Videos: http://web.mit.edu/18.06/www/Video/video-fall-99.html
Math: http://faculty.ccp.edu/faculty/dsantos/lecture_notes.html
Scientific Computing: http://www.cse.uiuc.edu/heath/scicomp/notes/
Linear Algebra: http://www.numbertheory.org/book/
Computation: http://web.comlab.ox.ac.uk/oucl/strachey/
Introductory Note: The book references are designated by (C), (C/O), (N/A), or left blank.
<!--[if !supportLists]-->(C) <!--[endif]-->The book is available only at the Carleton university library
(C/O) The book is available at both libraries: Carleton and university of Ottawa’s Morissette library.
“Blank” The book is only available at the university of Ottawa Morissette library.
How to use the document: The best way to use this document is to focus on what the professor teaches in the class, and to try
to understand the topics from the notes and the designated course textbook. If there is some
confusion, then the reader can refer to a reference.
ECO1192
MAT1320
GNG1100
CSI1102
ELG1100
MAT1341
CSI2114
ELG2130
CEG2131
MAT2331
SEG2100
PHY2323
PHY2310
MAT2322
ELG2135
SEG2101
CEG2151
CEG3131
CEG3151
CSI3310
CEG3150
CEG3180
SEG3310
CEG4131
CEG4193
CEG4161
CEG4392
ELG4172
CEG4311
CEG4185
ELG4132
CEG4153
Micellaneous
Course
Book
Internet
ECO1192
Engineering Economics by Chan S. Park (C/O)
>>
MAT1320
1)Engineering Mathematics by Anthony Croft, Robert Davison, Martin Hartgreaves (C)
1) http://www.sosmath.com/
2) http://www.mathcentre.ac.uk/resources/workbooks/mathcentre/web-integrationTRIGsub-.pdf
>>
GNG1100
1)Engineering Mechanics by R.C. Hibbeler (C/O)
2)Engineering Mechanics by J.L. Meriam, and L.G. Kraige (C/O)
3) Statics by J. L. Meriam (C/O)
1) http://home.san.rr.com/mccollums/Structures/Frames/index.html
2) http://www.ma.psu.edu/~herzog/em11/top.html
>>
CSI1102
1) http://java.sun.com/docs/books/tutorial/
2) http://www.particle.kth.se/~lindsey/JavaCourse/Book/courseMap.html
>>
ELG1100
1)Digital Design by Morris Mano (C/O)
2)Principles of Digital Design by Daniel Gajski (C/O)
>>
MAT1341
1)Linear Algebra with Applications by W. Keith Nicholson
2)Advanced Engineering Mathematics by Erwin Kreyszig (C/O)
>>
CSI2114
1)Data structures and algorithm analysis by Mark Allen Weiss (C/O)
2)Data Structures and Algorithms in Java by Robert Lafore (C)
http://ww0.java2.datastructures.net/presentations/
>>
ELG2130
1)Engineering circuit analysis by William Hayt (C/O)
2)Linear Circuit Analysis by Artice Davis
Solved Problems:
3)Schaum's Outline of Electric Circuits
by Joseph Edminister, Mahmood Nahvi (C/O)
5)Resistive Circuits by Daniel Babb (C)
http://eeclass.stanford.edu/cgi-bin/handouts.cgi?V_section=cat1035252336&cc=e40
FYI:
http://www.kimber.com/atomic-struct/tablecont.htm
>>
CEG2131
1)Computer organization by Carl Hamacher, Zvonko Vranesic, Safwat Zaky (C/O)
>>
MAT2331
Advanced Engineering Mathematics by Reza Malek Madani
http://www.efunda.com/math/math_home/
>>
SEG2100
Schaum’s outline of UML by Simon Bennett, John Skeleton, Ken Lunn (C)
See also SEG3310
>>
PHY2323
1)chapter 22, 23, 24, 25, 26, 27.1, 27.2, 28.1, 29.1-29.3, 29.5-29.7, 30, 31, 32.1, 32.3, 32.6, 34, University physics 1995, 1996 edition by Harris Benson
2)Vector Analysis by Murray Spiegel (C/O)
3)Electromagnetic Fields and Waves by Paul Lorrain (C/O),
Electromagnetism: Principles and Applications by Paul Lorrain
4)Schaum’s outline of Electromagnetics by Joseph Edminister (C)
1) http://web.mit.edu/6.013_book/www/
2) http://evangelion.mit.edu/802TEAL3D/index.html
3) http://www.jhu.edu/~signals/phasorapplet/phasorappletindex.htm
http://www.jhu.edu/~signals/phasorlecture2/indexphasorlect2.htm
See Misc. #1
>>
PHY2310
(Science Elective)
1)Optics by Eugene Hecht (4th edition)
2)Schaum’s outline of Optics by Eugene Hecht (N/A)
>>
MAT2322
1)Calculus with Analytic geometry by Edwards and Penney (C/O)
http://whitehead.math.berkeley.edu/courses/textsummer03.shtml (Multivariable Calculus)
>>
ELG2135
1)Microelectronic Circuits by A. Sedra, and K Smith (2nd edition)
2)Electronics:
Circuits and Devices by Ralph Smith (C/O)
http://eeclass.stanford.edu/cgi-bin/handouts.cgi?V_section=cat1035252336&cc=e40
>>
SEG2101
1)SDL:formal object-oriented language for communicating systems by Jan Ellsberger, Dieter Hogrefe, Amardeo Sarma
2)SDL illustrated : visually design executable models by Laurent Doldi
3)Compiler design in C by Allen I. Holub (C/O)
1) http://www.iec.org/online/tutorials/sdl/topic04.html
2) http://www.linux.com/howtos/Lex-YACC-HOWTO.shtml
3) http://java.sun.com/docs/books/tutorial/essential/threads/
>>
CEG2151
1)Digital Logic with VHDL Design by Stephen Brown, Zvonko Vranesic (C/O)
2)Design of Computers and other Complex Digital Devices by Sunggu Lee (C/O)
1) http://www.vhdl-online.de/
2) http://mikro.e-technik.uni-ulm.de/vhdl/
FYI:
http://www.ee.ic.ac.uk/pcheung/teaching/ee3_DSD/
>>
CEG3131
1)Design of Embedded Systems using 68HC12/11 Microcontrollers by Richard Haskell (en route UO)
2)Software and hardware engineering: Motorola M68HC11 by Fredrick M. Cady (C)
1) http://www.stanford.edu/class/ee281/lectures.html (main topics of a microprocessor course)
2) http://www.msoe.edu/eecs/ce/ceb/resources/ (Wookie: 68HC11 simulator)
FYI:
http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=02
>>
CEG3151
Design of Computers and other Complex Digital Devices by Sunggu Lee (C/O)
1) http://www.unf.edu/~swarde/Execution_Units/ALU_Design/alu_design.html
2) http://www-courses.cs.uiuc.edu/~cs232/lectures/
3) http://bwrc.eecs.berkeley.edu/Classes/CS152/index_lectures.html
4) http://www.stanford.edu/class/ee108b/
>>
CSI3310
1)Fundamentals of operating systems by Andrew Lister (C/O)
2)Modern Operating Systems by Andrew Tanenbaum (C/O)
>>
CEG3140/
CEG3150
1)Automatic Control Systems by Benjamin C. Kuo (C/O)
2)Digital Control Systems by Benjamin C. Kuo (C)
3)Control
Systems Engineering
by Norman Nise (C)
4)Modern Control Engineering by Katsuhiko Ogata
(C/O)
http://www.engin.umich.edu/group/ctm/
>>
CEG3180
1)Data communications for engineers by Michael Duck, Peter Bishop, Richard Read
2)Data communications and networking by Behrouz Forouzan
3)Computer Networks by Andrew Tanenbaum (C/O)
http://www.abo.fi/~xzhou/telecom.html
>>
SEG3310
1)http://www.cetus-links.org, http://oop.rosweb.ru/cetus/
2)http://www.omg.org/news/meetings/workshops/RT_2002_Workshop_Presentations/01-2_Douglass_RT_UMLTutorial.pdf
3) http://www.jeckle.de/umllinks.htm#tutorials
4) http://lgl.epfl.ch/teaching/software_engineering/documentation/articles/uml-2000-fucsos.pdf
5) http://lgl.epfl.ch/teaching/software_engineering/documentation/ocl-spec_1-5.pdf
6) http://www.embedded.com/showArticle.jhtml?articleID=13900141
7) http://www.dcs.qmul.ac.uk/~norman/SE-pages/Slides/UML%20Dynamic%20modelling.pdf
FYI:
http://www.omg.org/docs/ad/99-12-05.pdf
>>
CEG4131
1)Computer Architecture by John L. Hennessy, David A. Patterson (1990 edition)
(C/O)
2)Computer Architecture and Parallel Processing
by Kai Hwang and Faye Briggs (C/O)
>>
CEG4193
Distributed Systems: Principles and Paradigms by Andrew Tanenbaum and Maarten van Steen (C/O)
1) http://cs.gmu.edu/~setia/cs571-F02/slides/
2) http://www.uonbi.ac.ke/acad_depts/ics/course_material/ics618/ics319/
3) http://www.cswl.com/whiteppr/tutorials/modified.html#basic
4) http://java.sun.com/docs/books/tutorial/networking/index.html
5) http://www.cetus-links.org/
FYI:
Grid Computing
http://www.redbooks.ibm.com/redpapers/pdfs/redp3613.pdf
http://distributedcomputing.info/projects.html
>>
CEG4161
1)Real-Time Systems and Their Programming Languages by Alan Burns (1st edition 1990) (C)
2)Real-Time Systems by C. M. Krishna and Kang Shin (C)
1) http://www.cs.york.ac.uk/rts/RTSBookThirdEdition.html
2) http://www.abo.fi/~xzhou/realtime.html
3) http://www-unix.ecs.umass.edu/~krishna/697C-S04/rtcourse.html
4) RT UML & Statecharts: 1, 2. More here and here
5 ) SDL
4) Rose Real Time (Modelling Language Guide, Tutorials, Model Examples, C++
reference)
5) http://www-106.ibm.com/developerworks/forums/dw_forum.jsp?forum=332&cat=24&hideBody=true
>>
CEG4392
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/
See also CEG3131 and CEG2151
>>
ELG4172
Digital Signal Processing by Alan Oppenheim (C)
1) http://www.dspguide.com/pdfbook.htm
2) http://www.ece.mcmaster.ca/~gershman/slides_4tl4.pdf
>>
CEG4311
1)Digital Image Processing by Rafael Gonzalez (C/O)
2)Digital Image Processing Using MATLAB by Rafael Gonzalez
3)Digital Image Processing by Kenneth Castleman (C/O)
1) http://www.stanford.edu/class/ee368/handouts.html
2) http://www.imageprocessingbook.com/DIPUM/tutorials/tutorials.htm
3) http://www.mathworks.com/access/helpdesk/help/toolbox/images/
>>
CEG4185
1) http://csc.colstate.edu/kurkovsky/classes/6157/6157Slides.asp
2) http://www.ciise.concordia.ca/~assi/Lecture1.ppt
3) http://dpnm.postech.ac.kr/cs637/
>>
ELG4132
Modern VLSI Design by Wayne Wolf (C)
http://www.princeton.edu/~wolf/modern-vlsi/Overheads.html
>>
CEG4153
1) http://www.sosmath.com/trig/Trig5/trig5/trig5.html
2) Forward Kinematics, Inverse Kinematics
3) http://www1.cs.columbia.edu/~allen/F03/NOTES/invkin.full.pdf
4) http://www.math.ucsd.edu/~sbuss/ResearchWeb/ikmethods/iksurvey.pdf
5) http://www.imageprocessingbook.com/DIPUM/tutorials/tutorials.htm
6) http://www.mathworks.com/access/helpdesk/help/toolbox/images/
FYI: Related to link #2
Introduction, Homogeneous Transformations, Velocity Kinematics, Computer Vision, Path Planning
>>
Miscellaneous Notes:
The aim of the listed book references for PHY2323 is to provide the following:
<!--[if !supportLists]-->i) <!--[endif]-->The first one gives an understanding of the concepts of the course without the advanced math.
<!--[if !supportLists]-->ii) <!--[endif]-->The second introduces the math concepts. The main topics here are: gradient, divergence, curl, line integral, surface integral, volume integral, closed path and surface integrals.
<!--[if !supportLists]-->iii) <!--[endif]-->The fourth brings everything together.
A good understanding of Maxwell’s equations in the case of time constant fields (∂/∂t=0) and time varying fields (∂/∂t≠0) should be achieved. The aim of some of the problems in the course is to find two fundamental quantities E and H for the given charge or current configuration, and derive all other quantities such as potential, flux, and capacitance by using them.
Near the end of PHY2323 phasors will be covered. Phasors are a representation of sinusoidal functions in terms of their phase and amplitudes. You can visit internet link #3 to learn more about them.
2. MIT OpenCourseWare
<!--[if !supportLists]-->3. <!--[endif]-->Various Forums:
Engineering: http://www.eng-tips.com/
Engineering Software Forum:
http://www.eng-tips.com/threadcategory.cfm?lev2=22
Programming:
Java: http://forum.java.sun.com/forum.jsp?forum=31
VHDL: http://www.tek-tips.com/gthreadminder.cfm/lev2/4/lev3/32/pid/284
Assembly:
http://www.programmersheaven.com/c/MsgBoard/grouplist.asp
http://www.bipom.com/cgi-bin/yabb/YaBB.pl
http://www.roboticsindia.com/modules.php?name=Forums&file=viewforum&f=9
Math forum: http://mathforum.org/students/college/
Physics Forums: http://www.physicsforums.com/index.php
http://www.advancedphysics.org/
http://www.groupsrv.com/science/viewforum.php?f=1
http://physics.nad.ru/cgi-bin/forum.pl?forum=eng
IT forum: http://www.tek-tips.com/
Dictionary of Computing and Communications by Mcgraw-Hill (C/O).
Computers as Components by Wayne Wolf (C/O).
Embedded Systems Design by Peter Marwedel (C/O).
Online Computing Dictionary
Top
Engineering Mechanics, Statics (Hardcover)
by William F. Riley, Leroy D. Sturges
Optics:
http://physics.pdx.edu/~larosaa/Applied_Optics_464-564/Applied_Optics_464_564.html
http://www.physics.gatech.edu/gcuo/UltrafastOptics/index.html
http://www.bli.uci.edu/lammp/powerpoints/ECE_176/
http://www.eng.warwick.ac.uk/oel/courses/undergrad.htm
http://www.ph.ed.ac.uk/~wjh/teaching/optics/
http://www.phys.soton.ac.uk/quantum/lectures/ip2.pdf
http://www.phys.soton.ac.uk/quantum/lectures/ip4.pdf
http://www.phys.soton.ac.uk/quantum/lectures/ip6.pdf
http://www.phys.soton.ac.uk/quantum/lectures/ip9.pdf
ELG2130:
Elementary Linear Circuit Analysis by Leonard Bobrow
Fundamentals of Electric Circuits by C. Alexander and M. Sadiku
The Analysis and Design of Linear Circuits by R Thomas and A Rosa
Basic Circuit Theory by Lawrence Huelsman (More of a teaching reference not a textbook for students)
SEG2101: Design Methods for Reactive Systems: Yourdon, Statemate, and the UML by R. J. Wieringa
http://www.sintef.no/time/
http://www.sintef.no/time/UML_ArchDesign.pdf
http://www.sintef.no/time/timecomplete.htm
http://www.sintef.no/time/elb40/html/elb/sdl/sdl_t01.htm
http://books.elsevier.com/companions/1558607552/slides/slides.pdf
http://books.elsevier.com/companions/1558607552/slides/slides_handout.pdf
ELG Electrodynamics: http://www.ifh.ee.ethz.ch/%7Epascal/FuKII/SlidesII04.html
CEG3131:
?????Introduction to Embedded Microcomputer Systems: Motorola 6811/6812 Simulations
by Jonathan W. Valvano
Embedded Controller Hardware Design by Ken Arnold
Embedded Microprocessor Systems Design: An Introduction Using the Intel 80C188EB by Kenneth Short
CEG2151:
http://tisu.mit.jyu.fi/embedded/TIE341/TIE341.htm
http://www.async.ece.utah.edu/~myers/nobackup/ee3700_99/index.html (lectures)
http://www.imit.kth.se/courses/2B1513/
Circuit Design with VHDL by Voleni Pedroni
CEG3150:
http://tisu.mit.jyu.fi/embedded/TIE341/TIE341.htm
http://web.mit.edu/6.111/www/f2005/
Circuit Design with VHDL by Voleni Pedroni
CEG3180:
Computer Networks: A Systems approach by Larry Peterson
Computer Networks: Behrouz Forouzan
http://camars.kaist.ac.kr/%7ehyoon/courses/cs440/note_index.html
http://highered.mcgraw-hill.com/sites/0072515848/student_view0/index.html
CSI3310:
http://undergraduate.csse.uwa.edu.au/units/230.205/resources.html
http://www.int.gu.edu.au/courses/2010int/2010inthome.html
ELG4172:
http://www.ece.ubc.ca/~elec466/
http://www-sigproc.eng.cam.ac.uk/~ad2/3F3.html
ELG4132:
http://sina.sharif.edu/~hessabi/Adv_VLSI/index.html#Lecture%20Notes,%20Course%20Description,%20and%20Tentative%20Schedule
http://lsmwww.epfl.ch/Education/VLSI1-04/vlsi01_docs.html
http://lsmwww.epfl.ch/Education/former/2002-2003/VLSIDesign/toc.html
CEG4161:
Real-Time Systems by C. M. Krishna and Kang Shin
http://www.cs.york.ac.uk/rts/RTSBookThirdEdition.html
http://rtcl.kaist.ac.kr/~bkkim/lecture/ (real time control)
http://www.mathworks.com/products/stateflow/
http://www.caspur.it/risorse/softappl/doc/matlab_help/toolbox/stateflow/concep20.html#29877
ftp://ftp.software.ibm.com/software/rational/docs/v2003/win_solutions/rational_rosert/
CEG4311:
Digital Image Processing by Rafael Gonzalez
http://www.stanford.edu/class/ee368/handouts.html
ELG4132:
http://sina.sharif.edu/~hessabi/Adv_VLSI/index.html#Lecture%20Notes,%20Course%20Description,%20and%20Tentative%20Schedule
http://lsmwww.epfl.ch/Education/VLSI1-04/vlsi01_docs.html
http://www.cpe.ku.ac.th/~pom/courses/204424/2005/
ELG4172:
http://www.ece.ubc.ca/~elec466/
http://www-sigproc.eng.cam.ac.uk/~ad2/3F3.html
CEG4240:
Digital Control Systems by B.C. Kuo
Digital Control of Dynamic Systems by Gene Franklin, J Powell, Michael Workman
CEG4392:
http://www.altera.com/support/examples/exm-index.html
Miscallaneous:
Digital Arithmetic:
http://www.cs.ucla.edu/digital_arithmetic/viewgraphs_p.html
http://www.iis.ee.ethz.ch/~zimmi/publications/comp_arith_notes_l.ps.gz
Components and design techniques for digital systems:
http://www-inst.eecs.berkeley.edu/~cs150/fa04/Calendar.htm
Computer Architecture:
http://www.cs.berkeley.edu/~pattrsn/252S98/
http://www.eecs.harvard.edu/~dbrooks/cs146/
http://www.dcs.ed.ac.uk/teaching/cs3/comparch/slides.html
http://www-math.mit.edu/~edelman/18.337/BOOK/master.ps
http://www.stanford.edu/class/ee282/handouts.html
http://cva.stanford.edu/ee482s/notes.html
http://www.eecs.harvard.edu/~dbrooks/cs146/
Embedded Systems:
http://www.cs.lth.se/EDA380/
http://www.ida.liu.se/~TDTS30/lectures.en.shtml
http://www.tik.ee.ethz.ch/tik/education/lectures/ES/ES.html
http://www.tik.ee.ethz.ch/tik/education/lectures/ES/SS05/script/skript.pdf
http://ls12-www.cs.uni-dortmund.de/~marwedel/kluwer-es-book/slides.html
http://www.princeton.edu/~wolf/books.html
http://www.abo.fi/~jolilius/wwwold/G620/
Hardware/Software Codesign:
http://www.tik.ee.ethz.ch/tik/education/lectures/hscd/#literature
Digital Engineering
http://www.tik.ee.ethz.ch/tik/education/lectures/DRS/DRS.html
Discrete Systems:
http://www.tik.ee.ethz.ch/tik/education/lectures/DES/
http://www.tik.ee.ethz.ch/~dyer/
courses offered by ETHZ:
http://dcg.ethz.ch/courses.html
http://www.tik.ee.ethz.ch/db/public/tik/?db=lectures&form=report_list_lectures&collaborator=&grp=&period[]=Sommersemester&submitIt=search
http://www.tik.ee.ethz.ch/db/public/tik/?db=lectures&form=report_list_lectures&collaborator=&grp=&period[]=Wintersemester&submitIt=search
http://www.ife.ee.ethz.ch/education/lectures.html
Various books:
http://www.princeton.edu/~wolf/books.html
Stanford class webpages:
http://www-ee.stanford.edu/class_directory.php
Uni Dortmund:
http://www-ds.e-technik.uni-dortmund.de/new/CEI/de/main/index.shtml
http://si2.epfl.ch/~demichel/publications/mcgraw/powerpoint/
http://www.microlab.ch/cad_ex/5sem/ex551/ex_3.htm
http://ls12-www.cs.uni-dortmund.de/~niemann/cool/cool.html
http://ls12-www.informatik.uni-dortmund.de/edu/scripts-de.html
http://ls12-www.cs.uni-dortmund.de/%7Emarwedel/kluwer-es-book/slides.html
Research:
Research MIT:
http://web.mit.edu/research/
http://www.rle.mit.edu/rleonline/research/research_groups.html
http://www.eecs.mit.edu/labs.html
Research Utoronto:
http://www.eecg.utoronto.ca/projects.html
http://www.ece.utoronto.ca/English/Research.html
http://www.cs.toronto.edu/DCS/Research/index.html
Research ETHZ:
http://www.tik.ee.ethz.ch/~tec/
http://www.tik.ee.ethz.ch/~thiele/projects.htm
http://www.inf.ethz.ch/research/index
http://www.iis.ee.ethz.ch/
http://www.nari.ee.ethz.ch/
http://www.vision.ee.ethz.ch/
http://www.eeh.ee.ethz.ch/
http://www.ife.ee.ethz.ch/~macthest/index.html
http://www.photonics.ee.ethz.ch/?http://www.ife.ee.ethz.ch/%7erobin/CPG_Pub_Thema.html
http://www.oldimrt.ethz.ch/~geering/cog/demo.html
http://www.ifh.ee.ethz.ch/
http://www.eek.ee.ethz.ch/information/contact.html
http://www.nari.ee.ethz.ch/commth/
http://metamaterial.ethz.ch/MetaPeople.htm
Textbooks:
http://www.inf.ethz.ch/services/library/lehrbuch.htm
Harvard:
http://www.registrar.fas.harvard.edu/fasro/courses/index.jsp?cat=ugrad&subcat=courses/ChemistryandChemicalBiology.html
Scheduling – Theory, Algorithms, and Systems
Michael Pinedo
2nd edition, 2002
Prentice-Hall Inc.
Pearson Education
n The lecture is based on this textbook
SWE 621: Software Design
Table Of Contents -1
• Introduction to Software Design
– Overview of Software Design …………………………6
– Software Design Process……………………………….. 11
– Design Concepts………………………………………. 28
– Introduction to Software Design Methods……………….41
• Survey of Software Design Methods…..…………………….45
– Structured Design……………………………………..…47
– DARTS………..……………………………………..…..56
– Jackson System Development…………..…………….. ..59
– Naval Research Lab Method………………………..…...63
– “Early” Object-Oriented Design…………………….. ….67
– Comparison of Software Design Methods……………….76
SERIES Z: LANGUAGES AND GENERAL SOFTWARE
ASPECTS FOR TELECOMMUNICATION SYSTEMS
Formal description techniques (FDT) – Specification and
Description Language (SDL)
Slides for
Design Methods for Reactive Systems:
Yourdon, Statemate and the UML
Roel Wieringa
Department of Computer Science
University of Twente,
the Netherlands
roelw@cs.utwente.nl
www.cs.utwente.nl/roelw
1
SDL by example
This part of the SDL tutorial leads you through SDL by means of an example. You will learn about the various elements of SDL by clicking on the desired elements in the diagrams. In case parts of a diagram reference other diagrams, e.g. process references, clicking the name (in underlined blue or red ) will follow the reference and bring you to the referenced diagram.
If you want to be lead through the example top down, start with "System diagram, Access Control System" and follow the diagram references from there.You may alternatively choose to look at the kind of diagram you want to learn about.
"Introduction to the example" gives a short, informal introduction to the example being used throughout.
Package diagram, SignalLib
Package diagram, AccessPointLib
Block type diagram, AccessPoint
Block type diagram, BlockingAccessPoint
Block type diagram, LoggingAccessPoint
Process type diagram, Controller
Process type diagram, redefined Controller in BlockingAccessPoint
Process type diagram, finalised Controller in LoggingAccessPoint
Process diagram, Panel in terms of services
Service diagram, PanelControl
Procedure diagram, GetPIN
Introduction to the example
The purpose of access control systems is in general to control the access to some service to people with known identity, represented by cards and personal codes. In this specific example the system shall control access to access zones by controlling the opening of doors.
Each card holds a unique Card-code that identifies the card. To grant access the system will read the Card-code and then check the corresponding access right. For additional authentication, the user will be asked to enter the secret personal number (PIN).
Figure 15: Panel and card of an access control system
Open figure
The card is a plastic card with a magnetic strip holding a card code and possibly an encrypted PIN code. The physical appearance of the panel and the card is shown in Figure "Panel and card of an access control system" . Each panel represents an Access Point.
The main service demanded by the user is to gain access when the card and code is presented to the system, and to deny access if an attempt is made to enter at an access point where the user is not authorised to pass.
A typical access control system will consist of a number of access points and a central unit where validation is performed. Some access points are so-called blocking access points, that is access points that may be blocked by an operator, so that access is denied even with a valid card and code, until the access point is enabled again. Other access point may have the property that they log what is going on at the point.
In order to illustrate as many mechanism of SDL as possible, the example system will consist of three sets of access points, each of a different type. In a real access control system one may choose to give all access points the possibility of being blocked and of logging.
System diagram, Access Control System
Figure 16: System diagram for access control system with three types of access points
Open fiure
In SDL a system is defined by means of a system diagram. By making a system diagram it has been decided what is part of the system and what is part of the environment of the system.We choose to design the access control system such that the access terminals (called AccessPoints) are within the system, while the users actually getting access are outside the system. The CentralUnit containing the access rights is within the system, while for our current purpose, how the access rights information got into the CentralUnit is not described.
Before drawing this border between the system and the environment and thereby deciding what should be part of the system, a domain analysis will normally have taken place, different solutions will have been considered and different sketches of the system will have been tried out.
In this presentation, the final system description is presented top-down, in order to present the various SDL language elements.
This Access Control system consists of one single block (CentralUnit) and three block sets , that is sets of blocks according to block types, connected by channels . It communicates with the environment that is supposed to behave like processes representing the users of the system, the operators and the controlled physical panels and doors at the access points.
System
A system is in general a set of blocks , block sets and channels. Blocks and block sets are connected with each other or with the environment of the system by means of channels . This means e.g that there may not be processes directly as part of the system and systems will not have global variables.
Environment
For the system the environment consists of a set of SDL processes that may send signals to the system and which may receive signals from the system. The signals for this purpose are defined in the system or, as here, in a package ( Package diagram, SignalLib ) used by the system. The users of the system are thus regarded as processes in the environment.
Block
A block is created as part of the creation of the enclosing block or system. All blocks are created as part of the system creation, that is there is no dynamic creation of blocks.
The CentralUnit block is specified directly (singular block), while the other blocks of the system are parts of block sets according to block types. The symbol with CentralUnit is also a reference to a block diagram that describes the properties of the block.
Note that the block reference is merely a graphical shorthand for diagrams. Block references may be substituted by block diagrams, but the surrounding diagrams would be very crowded and illegible if diagrams could not be remotely referenced by block references. The reference defines the scope of the name.
block set
Type-defined blocks are contained in block sets. A block set is a fixed number of blocks with properties according to a block type. The set of AccessPoints is called ap and the number (100) designates the cardinality of the set. A channel connected to a block set (via the gates e or C) will actually represent a set of channel instances.
A block set is not a reference (as CentralUnit). It defines a set of block instances, but it relies on the definition of the block type AccessPoint. This block type definition is not part of the system, but part of the Package diagram, AccessPointLib and defined in "Block type diagram, AccessPoint" .
channel
Blocks and block sets are connected with each other and with the environment by means of channels. A channel is a one-way or two-way directed connection. It is characterised by the signals that it may carry. A channel has a signal list for each direction.
If there is no channel between two blocks, then processes in these two blocks cannot communicate by signal exchange. Processes may, however, communicate by means of remote procedure calls without channels connecting the enclosing blocks.
delaying channel
A delaying channel is specified by a channel symbol with the arrows at the middle of the channel.
The delay of signals is non-deterministic, but the order of signals is maintained.
non-delaying channel
A non-delaying channel is specified as folows, that is with the arrows at the endpoints. Associated with each direction of a channel are the types of signals that may be conveyed by the channel. The list enclosed by the signal list symbol can be signals (as e.g. Code) or signal lists (as e.g. validity) enclosed in ().
Channels connected to the frame symbol represent the connections to the environment.
package reference clause
A package reference clause specifies that a system diagram or package diagram use the definitions of other packages. The names following the "/" after the package name denotes the subset of the definitions that are used.
The system uses the types defined in the packages SignalLib and the denoted types (AccessPoint, BlockingAccessPoint and LoggingAccessPoint) from the AccessPointLib package.
Package diagram, SignalLib
Figure 17: Package diagram SignalLib
Open figure
This package defines all the signals being used in the access control system.
Defining a package SignalLib makes all the signal type definitions become globally defined, and they may be used by more than one system (without "copy-paste"). It is of course possible to let additional signals be defined locally in order to restrict the contexts in which they will be used.
package
A package is a collection of types, defined by a package diagram. A package may in general contain definitions of types, data generators, signal lists, remote specifications and synonyms. Definitions within a package are made visible to a system definition or other package definitions by a package-reference-clause (use clause).
The package in Figure 17 only contains definitions of signals.
signal definition
A signal definition defines a set of types of signals. A signal instance is a flow of information between processes, and is an instantiation of a signal type defined by a signal definition. A signal instance can be sent by either the environment or a process.
Signals may carry data values. The types of the values are specified as parameters of the signal definition. The signal Code defined in Figure 17 is defined to carry two integer values.
Signals may be defined in system and block diagrams, and these may then be used for communication between the blocks of the system or the processes of the block. Signals may also be defined in process (type) diagrams, but then they can only be used for communication between processes of the same set. Often signal definitions are collected in packages .
signal list
Often the lists of signals associated with channels and signal routes are quite comprehensive and diagrams become crowded. The notion of signallist helps on this. A signallist is a list of signals which has been given a name. Validity, inp and outp are signallists defined in the package and used in the system diagram.
text symbol
Text symbols are used in order to have textual specifications as part of diagrams, especially for specification of signal types, data types and variables.
There is no limit to the number of text symbols that may occur in a diagram. Text symbols are not connected to other symbols by flow lines.
The text symbol is also used for the graphical representation of a use clause, see Figure 17 .
Package diagram, AccessPointLib
The AccessPointLib package uses the signals defined in the package SignalLib (by the use clause) and defines three block types .
Figure 18: Package diagram AccessPointLib
Open figure
block type reference
Block types are referenced by means of block type references. Block types are defined in block type diagrams, and they are referenced by means of block type references . The block type reference indicates in which block or system scope unit the block type is defined. The three block type references in Package diagram AccessPointLib indicates that the scope of these are the package and not a specific system.
Note that the block type reference (as for block references) is merely a graphical shorthand for diagrams. Block type references may be substituted by block type diagrams.
Block type diagram, AccessPoint
The block type AccessPoint defines the properties of a general type of access point in the system. The other types of access points (blocking and logging access points) are defined a subtypes of this.
Each access point shall handle the interaction with the user via a panel, communicate with the central unit and control the door.
Figure 19: Block type AccessPoint with virtual Controller process type
Open figure
This block type diagram defines the block type with name AccessPoint in the AccessPointLib package. Each block instance of this type will consist of three process sets (Panel, Door, apc). The first two are defined in corresponding process diagrams (they are really just process references ), while apc is a set instances of process type Controller. The process type Controller is defined as a virtual process type , with the keyword VIRTUAL, so that specialisations of AccessPoint may replace that definition with their own definition.
The Panel takes of the physical panel, the Door process takes care of controlling the physical door, while the Controller process handles the communication with the CentralUnit in order to validate users of the access point.
Note the identifiers e and C which in the system diagram occurs inside the block set ap. These identifiers designate gates . Gates are used to indicate which channels of the block type are supposed to connect to which channel connecting an instance of the type. The gate names are defined by the type and visible wherever the type name is visible. Note also that the gate symbols have arrows at the ends and that signal lists are associated with the arrows. The signallists are constraints on the gates and will ensure that the instances of the block type are connected properly to their surroundings.
block type
A block type defines the common properties for a category of blocks. All block of the same type will have the same properties, as specified in the block type diagram.
Block types may contain a connectivity graph of block instances connected by channels. This makes up a structure of nested blocks. At the leaves of this structure there are blocks which contain processes. Blocks cannot contain both blocks and processes at the same level.
In addition to containing structures of blocks or structures of processes, block types may contain other type definitions. This makes up the scoping hierarchy of SDL. Names in enclosing type definitions are the only names visible.
Block types may contain data type definitions, but no variable declarations. This follows from the fact that processes in SDL do .fmnot share data other than signal queues. They share a signal queue in the way that one process appends (output) signals to the queue (the input port), while the other process consumes (input) signals from the same queue. Appending and consuming signals are atomic, non-interruptible operations. The input port is the basic synchronisation mechanism of SDL.
Block types may contain process types, service types and procedures as well as block types and data types.
block (type) heading
The heading of block type diagrams defines the name of the block type, possible formal context parameters, whether the block type is virtual or not and if it inherits from another block type. The block type in Figure 19 does not have any context parameters and it is not virtual.
process (reference)
A process reference specifies that there is a process set in the enclosing block and that the properties of this process are defined in a separate (referenced) process diagram outside this diagram. A process reference is a shorthand for having the referenced process diagram at this place in the surrounding diagram.
process set
A process set defines a set of processes according to a process type .
Just like we have the distinction between block reference, block type and block set according to type, we have the distinction between process reference, process type and process set according to a type. Our recommendation is that process sets should be described with reference to a process type.
While Panel above is a process reference, and thereby a process set without any associated type, apc is a process set according to the process type Controller and therefore not a process reference.
number of instances
In general process sets may have specified the number of instances in the set.
The numbers in parentheses after the process set name specifies the number of instances in the process set. As defined in above, there are initially no processes, and there is no limit on the number of instances that may be created.
signal route
A signal route represents a communication path between process sets and between process sets and the environment of the enclosing block/block type.
process type
A process type defines the common properties of a category of process instances. A process type is defined by a process type diagram .
virtual process type
A virtual process type is a process type that can be redefined in a subtype of the enclosing block type.
The virtuality is specified in the process type heading or by < virtuality > in the corresponding process type reference symbol, as is done here for the process type Controller.
A redefinition of the process type must be a subtype of the type identified in the virtuality constraint. As specified here the process type reference symbol has no explicit virtuality constraint , which means that any redefinition will extend the given definition of Controller (the Controller is its own constraint).
gate
A gate is a potential connection point for channels/signal routes when connecting sets of blocks/processes/services. The same symbol is used in all cases.
Gates are defined in block/process/service types and used when connecting sets or instances of these with channels/signal routes.
The signal list associated with the endpoints represents constraints (on incoming/outgoing signals) the gate.
Block type diagram, BlockingAccessPoint
Figure 20: Block type BlockingAccessPoint as a subtype of AccessPoint
Open figure
This block type defines a block type with name BlockingAccessPoint as a subtype of block type AccessPoint. It represents access points that may be blocked by some operator.
BlockingAccessPoints are quite similar to the plain AccessPoints.The only difference is that the BlockingAccessPoints shall be able to react to signals from the CentralUnit that plain AccessPoints will not recognise. BlockingAccessPoint will have a Door (which should not have a new definition), a Panel (which could have a new definition, but need not have a new definition) and a control process Controller which should be able to do the extended controlling.
A BlockingAccessPoint is a specialised AccessPoint where Controller is extended. This is expressed by the INHERITS clause of the block type heading.
The block type diagram specifies that BlockingAccessPoint inherits everything from AccessPoint, but it adds a redefinition of Controller and it adds two signal types on the inherited gate C: Enable and Disable. The fact the the gate is inherited is indicated by it being dashed.
In general, entities defined in supertype, inherited in subtypes and for which some additional properties have to be specified in the subtype, are called existing entities , and in the graphical syntax they are dashed entities .
redefined process type
A redefined process type is a redefinition of the corresponding virtual process type in the super block type, and it is virtual, so that it can be redefined in further subtypes of this block type .
A redefinition of the process type must be a subtype of the type identified in the virtuality constraint. In this case the constraint is not explicitly specified; this implies that the definition of the virtual process type is its own constraint: the redefinition thereby defines an extension (a subtype) of the virtual process type.
dashed entity
A dashed entity is the graphical way of representing an entity that is inherited from a supertype and which needs to be used in the definition of the subtype. There are dashed block sets, process sets, services and gates.
The Z.100 terminology is existing entity .
An existing block set/block may be connected by channel, and these will then be there in addition to those specified in the super type.
An existing process set/service may be connected by signal routes, and these will then be there in addition to those specified in the super type.
An existing gate can have constraints in terms of signals on the endpoints of the gate specified, and these are then added to the inherited gate and will then apply in addition to those of the inherited gate.
In the textual version of a specification, inherited entities are simply identified by name.
Block type diagram, LoggingAccessPoint
Figure 21: Logging AccessPoint as a subtype of AccessPoint
Open figure
This block type defines a block type with name LoggingAccessPoint as a subtype of block type AccessPoint, adding the process LogDevice.
With LoggingAccessPoint it is not sufficient to only modify the Controller, since there is an addition to the block, namely the LogDevice. The LogDevice must be connected to the Controller along a signalroute (which is added compared with the supertype AccessPoint). lsc has been defined in the AccessPoint definition and is dashed here.
We notice the keyword FINALIZED in the process type reference. This has a slightly different meaning than REDEFINED.
finalised process type
A finalised process type is a redefinition of the corresponding virtual process type in the super block type, and it is not virtual, so that it can not be redefined in further subtypes of this block type.
A final redefinition of the process type must be a subtype of the type identified in the virtuality constraint .
A redefined type can be redefined again in yet another specialisation. A finalised type cannot be redefined. There is a subtle point to making this distinction. Virtual and redefined types are very flexible, but analysis becomes more uncertain since some components may not be entirely known. Finalised types are not flexible any more, they are completely known and, therefore, analysis can be certain.
The new signalroute LD indicates that it is not be possible to derive the finalised Controller by only adding a number of new transitions to the basic Controller. In order to get new transitions, we need either new input signals or new states. The Controller of LoggingAccessPoint has neither new signals, which can be seen from the channels to the lap set of logging access points, nor new states. In fact the LogDevice should be invoked for most transitions since the requirement was to trace the transactions. Then our need is to modify (redefine) some of the existing transitions.
Process type diagram, Controller
Figure 22: Virtual process type Controller
Open figure
This process type heading defines the process type Controller as a virtual process type. This means that the process type can be redefined in a subtype of the enclosing block type.
Plain AccessPoints have their own (default) definitions of Controller.
A Controller process will start executing the start transition. In this case the start transition is empty and simply leads to the Idle state. The process will remain in the Idle state until it receives an input signal. It expects to receive a Code signal containing information about the card id and personal identity number from the Panel. It may, however, be prepared to receive other signals as well. The Idle state is followed by one input symbol which describes the consumption of the signal Code. If the process is in the Idle state and signals other than Code are received, they will be discarded.
We have defined three process gates P, D and U with associated process gate constraints. We note that the enclosing AccessPoint definition uses these gates in connection with the instance lsc of Controller.
Within the process type diagrams, the gates appear as identifiers in the VIA-clause of the output symbols.
When we want to analyse the type enclosing the virtual type (here, block type AccessPoint) we wish to know something about the instances of the virtual types even though we know they may be redefined in subtypes. At least we must know the static interface, i.e. the gates. Very often we would like to know more about the type and, therefore, the header of a virtual type may include a virtuality constraint . The virtuality constraint is of the form "atleast type-identifier". All "matches" (redefinitions and finalisations) of the virtual must be specialisations of the type referred to by the type-identifier of the constraint.
process type diagram
A process type diagram defines the properties of a process type. A process type defines the common properties of a category of process instances. A process type is defined by a process type diagram .
process type heading
The heading of process type diagrams defines the name of the process type, its virtuality (and constraint), its formal context parameters and if it inherits from another process type. The heading in Figure 22 defines a virtual process types without any context parameters and without any parameters.
variables in processes
Variables can be defined in processes, services and procedures. They are defined in text symbols.
SDL supports predefined types including Character, Boolean, Integer, Natural, Real and PId (Process Instance Identifier). The variables cid and PIN in Figure 22 are defined to be of type Integer, while the variable cur_panel is of type PId, which means that it denotes a process instance.
For a short introduction to the definition of user-defined types see "Specifying properties of variables: data types" .
Variables of process are created as part of the creation of the process instance.
Variables will get default initial values if nothing else is specified.
The following elements of SDL are used in the definition of Controller behaviour.
procedure reference
A procedure reference specifies that there is a procedure in the enclosing entity and that the properties of this procedure are defined in a separate (referenced) procedure diagram outside this diagram.
In the example here, unlockDoor is a procedure defined locally to Controller, and it is referenced by the symbol containing "unlockDoor" - that is there is a procedure diagram defining the properties of unlockDoor.
start
There is only one start symbol for a process. The transition from the start takes place when the process is generated. A process may be generated either at system start-up or as a result of a create request from another process.
The start transition in the Controller process is empty, that is there are no actions, so the process just enters the Idle state upon start.
transition
A transition performs a sequence of actions. During a transition, the data of a process may be manipulated and signals may be output.
Actions may be
task ,
output ,
set ,
reset ,
export
create request ,
procedure call , or
remote procedure call .
The transition will end with the process entering a
next state,
with a stop,
with a return or
with the transfer of control to another transition.
The controller process has three transitions : one starting in the state Idle and two in the state Validation. They are all input transitions, that is they are triggered by the consumption of a signal from the input queue of the process.
state
A state represents a particular condition in which a process may consume a signal resulting in a transition. If the state has neither spontaneous transitions nor continuous signals, and there are no signal instances in the input port, otherwise than those mentioned in a save, then the process waits in the state until a signal instance is received.
input
An input allows the consumption of the specified input signal instance (here of type Code).The variables associated with the input (here cid and PIN) are assigned the values conveyed by the consumed signal.
The values will be assigned to the variables from left to right. If there is no variable associated with the input for a sort specified in the signal, the value of this sort is discarded. If there is no value associated with a sort specified in the signal, the corresponding variable becomes "undefined".
The sender expression of the consuming process is given the PId value of the originating process, carried by the signal instance.
virtual (input) transition
A virtual input transition specifies that subtypes of type with this transition may redefine it, that is it must input the signal in the state, but the following transition may be redefined
A virtual input transition is a special case of a general notion of virtual transition:
virtual priority input,
virtual start,
virtual spontaneous transition.
In addition a save may be specified as a virtual save.
Redefinition of virtual transitions/saves corresponds closely to redefinition of virtual types:
A virtual start transition can be redefined to a new start transition.
A virtual priority input or input transition can be redefined to a new priority input or input transition or to a save.
A virtual save can be redefined to a priority input, an input transition or a save.
A virtual spontaneous transition can be redefined to a new spontaneous transition.
task
A task may contain a sequence of assignment statements or behaviour specified in informal text.
The example here is an assignment of (the predefined) SENDER, that is the sender of the signal triggering the transition of which this task is a part, to a PId variable cur_panel.
timer
In addition to assignments, task may specify the setting and resetting of timers . Timers are just like alarm clocks. The process waiting for a timer is passively waiting since the process needs not sample them. Timers will issue time-out signals when their time is reached.
A timer is declared similarly to a variable.
set timer
Timers are set and reset in tasks. When a timer has not been set, it is inactive. When it is set, it becomes active.
A timer is set with a time value. time is a special data type and is mainly used in connection with timers. The expression "now+10" is a time value and it adds the time expression now and the duration 10 (here:seconds). now is an operator of the time data type and it returns the current real time. Duration is another special data type and it is also mainly used in connection with timers. You may add or subtract duration to time and get time. You may divide or multiply duration by a real and get duration. You may subtract a time value from another time value and get duration.
The timer signal can be input in the same way as ordinary signals:
The semantics of timers is this: a time value is set in a timer and it becomes active. When the time is reached, a signal with the same name as the timer itself will be sent to the process itself. Then the timer becomes inactive.
A timer may be reset and it then becomes inactive and no signal will be issued. (If an inactive timer is reset, then it remains inactive.) A reset will also remove a timer signal instance already in the input port. This happens when the timer has expired, but the time-out signal has not been consumed.
If an active Timer is set, the time value associated with the timer receives a new value. The timer is still active. If a timer is set to a time which is already passed, the timer will immediately issue the time-out signal.
Timer signals may contain data as other signals may contain data. Different parameter values in set means generation of several timer instances. reset must match these parameter values to eliminate the correct timer instance.
For more details, see timers .
output
An output generates a signal of the specified signal type (here Code), containing the specified actual parameters (here cid and PIN), and send this signal instance to the specified destination.
The destination of a signal can be specified in various ways. The output symbol may in addition to the signal name (and actual parameters) contain a to-clause and/or a via-clause.
When the to- and via-clauses are omitted, there should be a unique destination for the signal based on the signal identifier. If there is a set of possible destinations, one of the destinations will be chosen non-deterministically. In our case the path and destination follow implicitly from the signalroutes and channels in the block diagrams.
When the to-clause is explicit, it specifies a process uniquely either by its (visible) name or by a "pointer" value. This "pointer" value in SDL is known as "PId" (Process Identifier). When a process is identified by its name in the to-clause, this means that it has to be within the same block since process names outside the block cannot be visible.
In order to specify the path the signal should follow, it is possible to append to the output statement a via-clause which lists the path of signalroutes and channels which the signal will be sent through. The VIA-clause may also specify a gate. Furthermore, the via-clause may be extended to "via all" and then if there is more than one channel instance in the path a signal instance will be generated for each channel instance. This happens for example when we have block sets. This is how we can describe a multicast message.
procedure call
A procedure call transfers the interpretation to the procedure definition referenced in the call, and that procedure graph is interpreted.
The interpretation of the transition containing the procedure call continues when the interpretation of the called procedure is finished.
Note that a procedure call symbol has one and only one entrance and one and only one exit. As specified here, the procedure has no parameters.
Process type diagram, redefined Controller in BlockingAccessPoint
Figure 23: Redefined process type with added states and transitions
Open figure
This process type defines the process type Controller (in block type BlockingAccessPoint) as a redefinition of the corresponding virtual process type in block type AccessPoint.
It is also specified that it inherits the same process type. This is, however, not necessary, as by default a redefinition of a virtual type without an explicit constraint will inherit the properties of the virtual type.
Inheritance of a process type implies inheritance of all states and transitions of the supertype. The asterisk state implies all states, also the inherited. The state Idle indicated as nextstate is the state Idle defined in the supertype.
For more details on this mechanisms, see virtual types and specialisation .
save
A save specifies that the signals in the save symbol are retained in the input port in the order of their arrival.
As specified in Figure 23 (an asterisk save) all signals except Enable are saved. For a given state there may be only one asterisk save,
The effect of the save is valid only for the state to which the save is attached. In the following state, signal instances that have been "saved" are treated as normal signal instances.
asterisk state
An asterisk state is a shorthand for all states except those listed in an accompanying asterisk state list.
The state names in an asterisk state list must be distinct and must be contained in other state list in the enclosing body or in the body of a supertype. As specified here, the asterisk state implies a state (with the corresponding transition) for each of the states except s1 and s2.
Process type diagram, finalised Controller in LoggingAccessPoint
Figure 24: Finalised process type
Open figure
This process type defines the process type Controller (in block type LoggingAccessPoint) as a finalised redefinition of the corresponding virtual process type in block type AccessPoint. This means that it is not virtual, so it can not be redefined in subtypes of the enclosing block type.
It is also specified that it inherits the same process type. This is, however, not necessary, as by default a redefinition of a virtual type without an explicit constraint will inherit the properties of the virtual type.
All transitions are inherited from the supertype, except the transitions starting with the state Validation and the signals OK and NOK. The are redefined in this process type.
For more details on this mechanisms, see virtual types and specialisation .
Process diagram, Panel in terms of services
Figure 25: Process in terms of services
Open figure
process diagram
A process diagram defines the properties of a process set , where each of the process instances in the set have the specified properties.
The behaviour of processes may be defined either by means of a procedure graph (states and transitions) or by means of a substructure of services connected by signal routes. The behaviour of each of the services is defined by means of states and transitions. The process defined in Figure 25 is defined by means of services .
process heading
The heading of process diagrams (defining a process set directly without any process type) defines the name of the process set and the initial/maximum number of instances in the set.
formal parameters
If the process shall have formal parameters they are also specified as part of the process heading. Formal parameters are (local) variables of the process instances. They get values as part of the creation of the process instance.
When a system is created, the initial processes are created in arbitrary order. The formal parameters of these initial processes have no associated values; i.e. they are undefined.
If the initial number is omitted (as in Figure 25 ), then the (default) value is 1. If the maximum number is omitted, then there is no limit on the number of instances.
service composition
As defined in Figure 25 the processes of this process set are defined by means of a composition of services . Service instances are components of the process instance, and cannot be addressed as separate objects. They share the input port and the expressions self, parent, offspring and sender of the process instance.
A service instance is a state machine, and it is described as in Figure 26 .
Service diagram, PanelControl
Figure 26: Service diagram, PanelControl
Open figure
When the process instance is created, the service starts are executed in arbitrary order. No state of any service is interpreted, before all service starts have been completed. A service start is considered completed when the service instance for the first time enters a state (possibly inside a called procedure) or interprets a stop.
Only one service at a time is executing a transition. When the executing service reaches a state, the next signal in the input port (which is not saved by the service, otherwise capable of consuming it) is given to the service that is capable of consuming it.
When a service ceases to exist, the input signals for that service are discarded. When all services have ceased to exist, the process instance ceases to exist.
variables in services
Variables can be defined in processes, services and procedures. They are defined in text symbols.
Variables of services are created when the service is created as part of the creation of the containing process instance.
Variables will get default initial values if nothing else is specified.
procedure call with parameters
A procedure may have formal parameters, and in the call the actual parameters are provided.
The pin parameter is in/out which means that the actual parameter corresponding to formal pin will be updated whenever the formal pin is updated within GetPIN. This is just like var parameters in Pascal or reference parameters in C++. The no_dig parameter is an in parameter which means that the procedure will have a local variable with the name of the parameter. This variable will assume the value of its corresponding actual argument at entry. Changes in the value of in parameters will not be transmitted to the actual argument. This is just like traditional value parameters.
Procedure diagram, GetPIN
Figure 27: Procedure diagram, GetPIN
Open figure
The PanelControl service referenced in Figure "Service diagram, PanelControl" is defined by the service diagram in Figure "Procedure diagram, GetPIN" .
procedure
Procedures define patterns of behaviour that processes/services may execute at several places or several times during their life-time. The behaviour of a procedure is defined in the same way as for processes (that is by means of states and transitions), a procedure may have (local) variables, and in addition it may have in, out, in/out parameters.
State names are not visible outside the procedure. The process states are not visible within the procedure.
The procedure in Figure 27 accepts a number of Digits as input signals in the state WaitDigit. The local variable i is increased by one for each digit, and when i equals the required number of digits, the procedure returns.
local variable
A procedure variable is a local variable within the procedure instance. It is created when the procedure start is interpreted, and it ceases to exist when the return of the procedure graph is interpreted. Variables will get default initial values if nothing else is specified.
procedure start
The start transition of a procedure is slightly different from the the start of process/service.
return
Procedure calls may be actions or part of expressions (value returning procedures only). A value returning procedure is a procedure where an expression is associated with the return, and the value of this expression is returned.
The interpretation of a procedure call causes the creation of a procedure instance and the interpretation to commence in the following way:
formal parameter
1. A local variable is created for each in parameter, having the name and sort of the in parameter. The variable gets the value of the expression given by the corresponding actual parameter if present. Otherwise the variable gets no value, i.e. it becomes "undefined".
2. A formal parameter with no explicit attribute has an implicit in attribute.
3. A local variable is created for each variable definition in the procedure-definition.
4. Each in/out parameter denotes a variable which is given in the actual parameter expression. The contained Variable-name is used throughout the interpretation of the procedure graph when referring to the value of the variable or when assigning a new value to the variable.
5. The transition contained in the < procedure start area > is interpreted.
The nodes of the procedure graph are interpreted in the same manner as the equivalent nodes of a process or service graph, i.e. the procedure has the same complete valid input signal set as the enclosing process, and the same input port as the instance of the enclosing process that has called it, either directly or indirectly.
remote procedures
A procedure may be exported by a (server) process, so that other (clients) processes (clients) can request these procedures executed by the server.
The remote procedure mechanism consists of four interdependent language constructs:
1. The exporting of a procedure . A procedure which is made visible by other processes is marked with the keyword exported preceding the procedure heading, e.g. "exported procedure Validate ..." from a process within the CentralUnit. The exporting process can control in which states it will accept the remote request. It may also specify to save the request to other states. The controlling of the acceptance is done by using input and save symbols with the remote procedure name preceded by the keyword procedure.
2. The importing of a procedure . When a process, service or procedure wants to import a remote procedure, it must specify the signature of this procedure in an "imported procedure specification" in a text area. The specification in our case would read: "imported procedure Validate; returns integer;" where the integer returned would give the result of the validation.
3. The specification of remote procedure . In SDL all names must be defined in a specific scope. Thus, the names of remote procedures must be defined in the context in which the actual definition of the procedure and the calls will be contained. In our case the definition of the procedure Validate is within the CentralUnit and the call is in Controller of the AccessPoint. The scope unit enclosing all these is the system itself. There we will find a text area with the following text: "remote procedure Validate; returns integer;".
4. The calling of a remote procedure . The calling of the remote procedure is indistinguishable from local procedure calls unless the caller explicitly states which process it will request the procedure executed by. This can be done by a to-clause with a PId following the procedure name of the call.
Remote procedures may be value returning (as in our example above), and they may be virtual.
Block diagram, CentralUnit
Figure 28: Block diagram defining the CentralUnit
Open figure
create
A process may create processes in other process sets in the same block, possibly providing actual parameters to the new instance.
The create line (dashed line with arrowhead) indicates possible creations.
Create lines are optional.
create action
As specified in Figure 28 the process CUControl creates Validation processes. In the process graph of CUControl, the creation will be specified by a create action.
Text Processing For Speech Synthesis
Using Parallel Distributed Models
IEEE
Michael S. Scordilis
John N. Gowdy
Electrical & Computer Engineering
Clemson University
Clemson, South Carolina
Abstract
Mapping letters to phonemes is a fundamental
problem in automatic speech conversion and arises
from the fact that no complete set of rules exists to
account for all the different pronunciations of letter
groups in English. Although a number of algorithms
containing thousands of rules are being used in textto-
speech synthesis, parallel distributed models have
shown the potential of processing speech much more
efficiently. Here, as part of a new approach to the
synthesis problem, such a model is presented. This
model includes a procedure which marks those
incoming letters which are soundless, but which
modify the pronunciation of their neighbors.
Introduction
As part of the ongoing activities aimed at
improving man-machine interfaces, unrestricted
speech conversion has been the subject of long
research efforts. Speech synthesis is used by choice
when visual information is not desired or by necessity
in the case of visually impaired system users.
Although several commercially available speech
synthesis systems are, for the most part, successful
in producing intelligible speech, the goal of
synthesizing pleasant and natural sounding voices is
still elusive. Renewed interest in the design of
improved methods has been generated with the
introduction of the CD-ROM technology [l]. Such
devices are capable of storing databases in excess of
500 Mbytes.
The difficulty of the speech synthesis problem
arises mainly from the nature of human speech
itself. Speech is characteristically a cognitive activity,
and requires an understanding of the text segment to
be spoken in order for the ideal, "natural" utterance
to be produced. Language understanding requires
the development and use of an artificially "intelligent"
machine, a difficult problem in itself. In
addition to this universal property of speech production,
synthesizing in English is further complicated
by the anarchic nature of the English language,
in which letter to sound correspondence cannot be
adequately described by a simple set of rules. Word
pronunciation is heavily dependent on context and is
also a function of many variables a- mong which are
geographical and historical factors.
Text Processin9
Text-to-speech conversion begins with high level
processing of the incoming text before the synthesis
process is evoked. An integral part of this phase is
the conversion of the symbols and abbreviations
present in the text segment into standard orthographic
form with the use of a set of rules and a
dictionary. For example, "1989" is converted into
"nineteen eighty nine" and "Mr." into "Mister" before
any phonological or linguistic analysis is attempted.
Once all such strings have been converted, phonetic
transcription is performed on the normalized text [2].
The block diagram in figure 1 shows the typical parts
of the high level processing stage in a speech
synthesis system.
Phonetic transcription is the process which
accepts orthographic text and produces the appropriate
phonemic sequences. In other words, this is
the mapping of letters into phonemes, the basic
sounds of a language. Several quite successful algorithms
have been used for transcribing text into
phonemic strings. These algorithms contain hundreds
of rules and extensive tables of exceptions and
have proven quite successful [2,3,4,51. However, all
these rule-based systems recognize the fact that no
complete set of rules able to cover all cases of the
language can be devised. Therefore, they make the
provision of including a user updated lexicon. The
user is able to update the standard system with any
new words or pronunciations not originally included.
In the case of new unrestricted text, however, such a
solution can work only if someone has already read
the text segment and "tuned" the user lexicon
accordingly. The limitations of such a method are
quite obvious and are a major factor in the less than
enthusiastic acceptance of speech synthesizers in the
computer market.
e Proceedings - 1989 Southeastcon
765 CH2674-
Hospital da Trofa is a small privately run hospital near Porto in Northern Portugal. It was one of the partners in a European Commission funded project
SEG 3150 Winter 2005: Telecommunications Software Engineering
News
<!--[if !supportLists]-->· <!--[endif]-->Chapters in Stallings that are relevant for the exam (as shown in the Friday, April 8 lecture)
<!--[if !supportLists]-->· <!--[endif]-->The final 2005 version of the lecture notes is available, including up to Tuesday April 5.
<!--[if !supportLists]-->· <!--[endif]-->The TA has resigned her position to take a full-time job, so there will be a delay in the grading of assignment 2.
<!--[if !supportLists]-->· <!--[endif]-->Final exam: Monday April 18, 09:30 – 12:30, MRT 212
Note that the SEG 3550 section will also have their exam in the same room.
<!--[if !supportLists]-->· <!--[endif]-->Assignment 3 deadline: Thursday April 7, 23h55.
Links within page
Course Description
Schedule
Lecturer
Teaching Assistants
Text
Course plan
Course materials
Labs
Assignments
Evaluation
Course Description
The official description:
Principles of information transfer
Error control, flow control, congestion control, routing algorithms.
Principles of telecommunications system software design and analysis.
The material will cover the following chapters from Stallings, although we will not be proceeding step-by-step through the text. There will be additional material covering the software engineering topics.
Review: Overview of networks, layered architecture, standards [Chapters 1, 2]
Data transmission: bandwidth, propagation delay, channel capacity, impairments [Chapter 3]
Error control [Chapter 6/7]
Framing [Chapter 7]
Flow control [Chapter 7]
Local Area Networks [Chapters 15/16/17]
Internet protocols [Chapter 18]
Congestion control, traffic management [Chapter 13]
Routing [Chapter 12/19]
Schedule
Lectures:
<!--[if !supportLists]-->· <!--[endif]-->Tuesday, 08:30 – 10:00, VNR 462
<!--[if !supportLists]-->· <!--[endif]-->Friday, 10:00 – 11:30, STE B0138
UML has broad tool support
– I-Logix
– Rational
– Paradigm
• UML supports real-time systems
www.cs.york.ac.uk/rts/RTSBookThirdEdition.html
SEG4140
Introduction to Real-Time
and Embedded Systems.
Goal 1: The implementation of signal
processing systems in CMOS technology
» A design methodology starting from a high
level description through to an
implementation optimized for hardware
constraints.
l Goal 2: To understand the issues involved
in the design of wireless systems
» Wireless systems will be used as a design
driver to understand how to make tradeoffs
in signal processing implementation
Eq.(8-12)
Eq.(8-13)
Eq.(8-14)
out of phase. The voltage phasor is advanced by 90
. When the voltage phasor is advanced counterclockwise(that is, ahead of the rotating current phasor), we say that the voltage phasor leads the current phasor by 90
Eq.(8-15)
Eq.(8-17)
and 
. Find the impedance of the elements in the rectangular box.
and 
. Using Ohm's law in phasor form, we find that 
. Solving form the unknown voltage yields 
V
. Given the phasor voltage across and current through the unknown element, we find the impedance to be
)
)
)
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}