I've used Enterprise Architect (EA) to create pretty drawings and I've liked it for that purpose. I find that I have a lack of understanding on how diagram elements link between one another. What I find particularly frustrating is that there is very little documentation on how this linking works (although lots of documentation on how to draw pictures).
I would like to create a model of a simple processor/ECU (electronics control unit). Here is the behaviour:
An ECU has an instance of NVRAM (which is just a class) for an attribute
An ECU has a voltage supply (an analog value representing the voltage level supplied to the ECU)
An ECU has two digital input ports
Each digital input port fires signals when its value changes
the ECU has a state machine with three states; the state machine enters state 1 on entry; the state machine transitions to state 2 on a firing of either digital input ports so long as the ECU voltage supply is greater than 10 V
the ECU exists to state 3 when Voltage drops below 8; and goes back to normal processing when Voltage rises above 9
Can you develop a model that demonstrates how these elements interact? (Is there some reference I can read on how to understand this approach?)
Here's my first attempt:
State Machine
I used a composite diagram in the ECU state so that I could have access to the digital ports diagramatically. I created a link for each port so that they "realize" class input PIn. I assume I can depict class attributes this way.
I "create a link" so that the DIO triggers realize the DIO ports. Not sure I can do this.
The class state machine is where I get lost. Not sure on how to create a trigger for ECU.Voltage < 8.
Related
In Autosar NM 4.2.2 NM PDU Filter Algorithm,
What is significance of CanNmPnFilterMaskByte . I understood that it is used to Mask(AND) with incoming NM PDU with Partial Network info and decide to participate in communication or not. But please explain how exactly it works in brief.
You are actually talking about Partial Networking. So, if certain functional clusters are not needed anymore, they can go to sleep and save power.
ECUs supporting PN check all NmPdus for the PartialNetworkingInfo (PNI, where each bit represents a functional cluster status) in the NmPdus UserData.
The PnFilterMask actually filters out any irrelevant PNI info, the ECU is not interested in at all (because the ECU does not contribute in any way to these functions). If after applying the filter, everything is 0, the NmPdu is discarded, and does therefore not cause a restart of the Nm-Timeout Timer. Which brings actually the Nm into the Go-to-sleep phase, even though, NmPdus are still transmitted.
By ECU, also consider Gateways.
Update how to determine the mask
As described above, each bit represents a function.
Bit0 : Func0
..
Bit7: Func7
The OEM would now have to check, which ECUs in the Vehicle are necessary for which functions (also at certain state) required or not, and how to layout the vehicle networks.
Here are some function examples, and ECUs required excluding gateways:
ACC : 1 radar sensor front
EBA : 1 camera + 1..n radar sensor front
ParkDistanceControl (PDC): 4 Front- + 4 Rear Sensors + Visualization in Dashboard
Backup Camera: 1 Camera + Visualization ECU (the lines which tell according to steering angle / speed where the vehicle would move within the camera picture)
Blind Spot Detection (BSD) / LaneChangeAssist (LCA): 2 Radar sensors in the rear + MirrorLed Control and Buzzer Control ECU
Rear Cross Traffic Assist (RCTA) (w/ or w/o Brake + Alert): 2 Radar Sensors in the rear + MirrorLed Control and Buzzer Control ECU
Occupant Safe Exit (warn or keep doors closed in case something approaches): 2 rear radar sensors + DoorLock ECU(s)
The next thing is, that some functions are distributed over several ECUs.
e.g. the 2 rear radar sensors can do the whole BSD/LCA, RCTA, OSE functions, including maybe LED driver for the MirrorLEDs and a rear buzzer driver, or the send this information over CAN to a central ECU which handles the MirrorLEDs and a rear buzzer. (such short range radar sensors is, what I'm doing now for a long time, and the number of different functions grows over the years)
The camera can have some companion radar sensors (e.g. the one where ACC runs on or some short range radars) to help verify/classify image data / obejcts.
The PDC sensors are maybe also small ECUs giving out some information to a central PDC ECU, which actually handles the output to the dashboard.
So, not all of them need to be activated all the time and pull on the battery.
BSD/LCA, RCTA/B need to work while driving or parking, RCTA/B only when reverse gear is selected, BSD/LCA only with forward gear or neutral, PDC only when parking (low speed forward/reverse), Backup Camera only when reverse gear is in for parking, OSE can be active while standstill, with engine on (e.g. drop off passenger at traffic light) or without engine on (driver leaves and locks vehicle).
Now, for each of these cases, you need to know:
which ECUs are still required for each vehicle state and functional state
the network topology telling you, how these ECUs are connected.
You need to consider gateway ECUs here, since they have to route certain information between multiple networks.
You would assign 1 bit of the Nm Flags per function or function cluster (e.g. BSD/LCA / RCTA = 1bit, OSE = 1bit, BackupCam / PDC (e.g. "Parking mode") = 1bit
e.g. CanNmPnInfo Flags might be defined as:
Bit0 : PowerTrain
Bit1 : Navi/Dashboard Cluster
Bit2 : BSD/LCA/RCTA
Bit3 : ParkingMode
Bit4 : OSE
...
Bit7 : SmartKeyAutomaticBackDoor (DoorLock with key in near to detect swipe/motion to automatically backdoor)
It may also be possible to have CL15 devices without PNI, because the functions are only active while engine is on like ACC, EBA, TrafficJamAssist ... (even BSD/LCA/RCTA could be considered like that). You could handle them maybe without CL30 + PNI.
So, you now have an assignment of function to a bit in the PNI, and you know which ECUs are required.
e.g. the radar sensors in the rear need 0x34 (Bits 2,3,4), even though, they need to be aware of, that some ECUs might not deliver infos anymore, since they are off (e.g. Speed, SteeringAngle on Powertrain turned off after CL15 off -> OSE) and this is not an error (CAN Message Timeouts).
The gateway might need some more bits in the mask, in order to keep subnetworks alive, or to actually wake up some networks and their ECUs (e.g. Remote Key waking up DoorLock ECUs)
So a gateway in the rear might have 0xFC as a mask, but a front gateway 0x03.
The backup camera might be only activated in low-speed (<20km/h) and reverse gear, to power it up but PDCs can work without reverse gear.
The PNI flags are actually usually define by the OEM, because it is a vehicle level architectural item. This can not be defined usually by a supplier.
It should be actually part of the AUTOSAR ARXML SystemDescription. (see AUTOSAR_TPS_SystemTemplate.pdf)
EcuInstance --> CanCommunicationConnector (pnc* Attributes)
Usually, the AUTOSAR Configuration Tools should support to automatically extract this information to configure CanNm / Nm and ComM (User Requests) automatically.
Sorry for the delay, but finding a example to describe it can be quite tedious,
But I hope it helps.
MODBUS is positioned as a universal data transferring protocol which works in almost every media.
When working with industrial devices they are usually using several slots to maintain different types of I/O modules.
I've read in modbus.org docs that the enumeration of coils (Digital Outputs) is starting from 0 position.
In the PDU Coils are addressed starting at zero. Therefore coils
numbered 1-16 are addressed as 0-15
Currently the slots are used in this way. Module 5056D (DO module) is connected as second.
Would the accessing address to the first Digital Output change from 00 to another if the module is swapped with neighbor modules or it would change only if to insert another DO module in the first slot?
Then I guess it would be 16+1=17; 17-1=16 accessing address=16?
What are the properties of a wireless sensor node ?
From Omnet++ manual i came to know that
simple wirelessnode
{
gates:
input radioIn;
parameters:
...........
}
Though the node have only input gate , how it sending data to other node?
if the node is wireless how the sensor node connected ?
How to define a region around a wireless sensor node for reach another node in range?
Thanks
For sending, you can think with a DODAG : take a tree, put the root as the gate. The gate gathers the data of its children, each of those children gathring themselves the data of their children ... the leaves are the nodes that need the more hops to be reached from the root.
Here you would need, among others : the power of the transmitting, the power of the receiving chip (so that if the sending node is too far away then the receiving node won't catch its frame for example, as pointed by user4786271), a protocol to route them (so that if a node has 2 other nodes in range of rank n-1, to know which one it will use).
Try to dig into some open source WSN simulators implementing protocols, you could get a lot of info. For example : https://bitbucket.org/6tisch/simulator/src
To answer your exact question, there is no such thing like "general properties" for a given module when designing a protocol.
Usually the decision of the module properties that you are going to use, is strongly related to what that node is supposed to do as part of your protocol.
If your node is never going to communicate, there is no point in adding a gate to it.
Though the node have only input gate , how it sending data to other
node?
You don't have to strictly adhere to the design that you have seen. Maybe in that case the nodes only need to receive messages. In your case you might want to define an output gate.
if the node is wireless how the sensor node connected ?
Do not view the gates as physical entities, but rather as interfaces which are capable of communicating through links. Do you see a cable link between your mobile phone and the basestation? Probably not, because they are connected through a wireless link. So your mobile phone has an interface for wireless link. See where I am going? In your case you will need a gate with wireless link.
How to define a region around a wireless sensor node for reach another
node in range?
Hmm, based on your propagation model the received signal power will depend on the distance, right? You can check the received power for the MAC frame and dismiss it if it is below a given threshold.
Or, if you work on the application layer -- which you don't -- you can embed location information in your packets and then perform pairwise distance comparison to decide packets from which sender to consider or drop.
I've been coding a 16-bit RISC microprocessor in Verilog, and I've hit yet another hurdle. After the code writing task was over, I tried to synthesize it. Found a couple of accidental mistakes and I fixed them. Then boom, massive error.
The design comprises of four 16-bit common buses. For some reason, I'm getting a multiple driver error for these buses from the synthesis tool.
The architecture of the computer is inspired by and is almost exactly the same as the Magic-1 by Bill Buzzbee, excluding the Page Table mechanism. Here's Bill's schematics PDF: Click Here. Scroll down to page 7 for the architecture.
The control matrix is responsible for handling when the buses and driven, and I am absolutely sure that there is only one driver for each bus at any given instance. I was wondering whether this could be the problem, since the synthesis tool probably doesn't know this.
Tri-state statements enable writing to a bus, for example:
assign io [width-1:0] = (re)?rd_out [width-1:0]:0; // Assign IO Port the value of memory at address add if re is true.
EDIT: I forgot to mention, the io port is bidirectional (inout) and is simply connected to the bus. This piece of code is from the RAM, single port. All other registers other than the RAM have separate input and output ports.
The control matrix updates a 30-bit state every negative edge, for example:
state [29:0] <= 30'b100000000010000000000000100000; // Initiate RAM Read, Read ALU, Write PC, Update Instruction Register (ins_reg).
The control matrix is rather small, since I only coded one instruction to test out the design before I spent time on coding the rest.
Unfortunately, it's illogical to copy-paste the entire code over here.
I've been pondering over this for quite a few days now, and pointing me over to the right direction would be much appreciated.
When re is low, the assign statement should be floating (driving Zs).
// enable ? driving : floating
assign io [width-1:0] = (re) ? rd_out [width-1:0] : {width{1'bz}};
If it is driving any other value then the synthesizer will treat is as a mux and not a tri-state. This is where the conflicting driver message come from.
I'm using a Virtex 5 FPGA and want to have a few +5/0 I/O pins to communicate with a microcontroller. The only peripherials I've used on the board so far are pushbuttons and switches and no one I've asked seems to know the simplest way to do this I/O. I've looked around the board specification but haven't found any simple way of doing it. I would appreciate any advice you might have.
This is not an easy thing to do. If you don't have the schematic of the board, then you need to get volt meter with some fine pitch probes and reverse engineer the board.
It is pretty easy if you have 2 boards, with one board it can be really hard since the BGA signals may not be connected to a via and therefore not available on the bottom of the board, and even if they are, then you don't know exactly which pin they are connected to. But with some luck, you can find them since the VIA can only be connected to 4 possible pins surrounding it!
The first thing you need to do is to identify your chip, find the BGA print of the IC from Xilin'x web site.
If your board has some buttons already, then if you are lucky, those signals may be routed to the pins of the FPGA that are available on the bottom of your board. Here are the things you need to do:
Make sure you have good ESD protection to perform these test
Put your voltmeter into 'buzzer' mode
Check the pins of your connector and find out how it is connected, see if there is a pull-up and/or pull-down resistors on the board
when you find the 'active' pin of your connector, start connecting the other probe to the VIAs one by one
When you hear a buzz, make a note of the position (guess or measure the distance between the side of t he IC and the location of the via)
Identify the 4 possible pins that the signal can be connected to
Write a code to get all those 4 signals and connect them to ChipScope
In Chip Scope, capture all 4 signals and see which one is the one with the right connection!
alternative, you can create a design with inputs only, capture all the inputs and put them into a memory block and create a trigger logic to capture all the signals whenever any of the inputs changes, after lots of work and analysis, you will find the correct pins.
Anyway, these are just crazy ideas since this is a really difficult thing to do without having the PCB info of the board.
Good luck with your hacking.